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Disclaimer 


Certain  commercial  products  are  identified  in  this  document.  Such 
identification  does  not  imply  recommendation  or  endorsement  by  the 
National  Institute  of  Standards  and  Technology,  nor  does  it  imply 
that  the  products  identified  are  necessarily  the  best  available  for 
the  purposes  stated. 


1.  Introduction 


1.1  Background 

Federal  government  agencies  are  no  longer  required  to  acquire  Open 
Systems  Interconnection  (OSI)  products  in  support  of  their 
networking  requirements,  because  it  was  recognized  that  there  was 
no  single  solution  for  meeting  these  requirements.  Technology  is 
advancing  at  a rapid  rate,  and  cost  is  an  important  factor  in  any 
procurement  decision.  Users  must  balance  the  services  provided 
with  the  expected  cost  and  be  prepared  to  make  tradeoffs.  Today, 
there  are  many  disparate  information  systems,  providing  a variety 
of  network  services.  Interoperability  and  interworkability  among 
these  systems  is  problematic  at  best'.  Accomplishment  of  user 
missions  is  limited  by  capabilities  of  existing  equipment.  To  a 
large  extent,  users  are  still  locked  into  proprietary  solutions, 
and  this  situation  is  not  entirely  unpleasing  to  their  vendors. 
Administratively,  organizations  are  continuing  to  decentralize,  so 
the  need  for  networking  services  is  increasing. 

1.2  Purpose 

The  absence  of  a single  solution  for  providing  global  data 
communications  interoperability  gives  users  more  flexibility  in 
making  procurement  decisions.  It  also  gives  them  more 
responsibility  for  making  the  right  choice.  In  order  to  make  more 
informed  decisions,  users  need  to  be  more  knowledgeable  about  the 
current  state  of  computer  networking  technology  and  the  planned 
advances  in  that  technology.  Users  must  also  be  aware  of  the 
vendors'  plans  for  marketing  that  technology.  Only  by  integrating 
all  of  this  information  with  their  own  requirements  will  users  be 
able  to  make  intelligent  procurement  decisions. 

This  document  will  survey  the  services  that  are  currently  provided 
by  non-proprietary  communications  technology  and  that  are  expected 
to  be  provided  in  the  foreseeable  future.  When  the  services 
provided  by  the  different  protocols  are  similar,  the  differences 
will  be  highlighted  to  assist  users  in  making  the  right  choice. 
There  will  also  be  an  assessment  of  the  degree  to  which  the  major 
protocols  or  protocol  suites  have  gained  or  are  expected  to  gain 
marketplace  acceptance.  It  will  be  impossible  to  accurately 
predict  all  of  the  circumstances  that  can  influence  a future 
procurement  so  whenever  possible,  the  contingency  factors  that  will 
affect  future  events  will  be  specified.  In  summary,  it  is  the 
intent  of  this  document  to  arm  the  reader  with  the  best  information 
available  to  assist  in  the  procurement  of  non-proprietary 
communications  products  and  services. 

1.3  Scope 

Although  the  mandate  to  acquire  OSI  technology  to  provide 
interoperability  between  heterogeneous  computer  systems  has  been 
removed,  the  National  Institute  of  Standards  and  Technology  (NIST) 
continues  to  believe  that  solutions  to  computer  networking 


1 


requirements  that  do  not  lock  users  into  the  services  of  a single 
vendor  are  in  the  long-range  interests  of  most  users.  Accordingly, 
this  report  will  focus  on  providing  non-proprietary  solutions  to 
those  requirements. 

1.4  Organization  of  the  Document 

This  section  (section  1)  provides  an  introduction  to  the  rest  of 
the  document.  Section  2 contains  information  about  the  most  widely 
implemented  non-proprietary  data  communications  protocols  and  the 
services  that  they  provide.  Section  3 contains  alternative 
strategies  for  users  to  consider,  given  the  information  in  section 
2. 
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2.0  Computer  Networking  Services  and  Architectures 

2.1  Internet  Protocol  Suite  (IPS) 

2.1.1  General  Process 

2. 1.1.1  History 

In  the  early  1970 's,  the  Defense  Advanced  Research  Projects  Agency 
(DARPA)  of  the  Department  of  Defense  (DOD)  instituted  research  in 
order  to  develop  a mechanism  for  preserving  critical  information  in 
case  of  foreign  attack.  The  research  was  considered  experimental, 
and  involved  the  ability  to  transfer  information  easily  and  quickly 
from  one  computer  to  another.  Initially  several  machines  were 
connected  at  several  academic  communities  (Massachusetts  Institute 
of  Technology  (MIT) , Stanford,  Utah,  University  of  California  at 
Berkeley);  thus  the  Internet  was  born.  In  1977,  early  versions  of 
the  Transmission  Control  Protocol  (TCP)  and  Internet  Protocol  (IP) 
began  to  be  developed  on  the  experimental  Internet.  TCP  and  IP 
collaborated  to  route  and  reliably  transfer  data  packets  between 
the  source  and  destination  end  systems.  Before  TCP  and  IP  were 
developed,  ad  hoc  solutions  were  used.  A more  mature  and  bigger 
Internet  was  created  in  1980  when  DARPA  began  to  connect  computers 
on  many  of  its  research  networks  using  the  new  TCP/IP.  In  1981  the 
Internet  effort  had  grown  to  the  point  that  the  DARPA  Program 
Manager  formed  an  advisory  group,  called  the  Internet  Advisory 
Control  Board  (lACB)  to  advise  DARPA  in  managing  the  operation  of 
the  Internet.  Initially  consisting  of  eight  members,  it  is 
essentially  the  same  management  structure  that  is  in  place  today. 
DARPA  funded  the  inclusion  of  TCP/IP  into  UNIX  4.1  Berkeley 
Software  Distribution  (BSD)  in  1981  and  the  distribution  of  source 
code  by  Sun  Microsystems  in  1982.  Informal  testing  groups  resolved 
any  operational  problems.  The  transition  to  Internet  technology 
accelerated  in  January  of  1983  when  DARPA  mandated  that  all 
computers  connected  to  its  research  networks  use  TCP/IP  to  provide 
a networking  infrastructure. 

Another  key  factor  in  the  rapid  expansion  of  the  Internet  was  the 
involvement  of  the  National  Science  Foundation  (NSF) , which  funded 
regional  networks  in  1985,  and  funded  a national  backbone  to  link 
those  regional  networks  in  1987,  using  TCP/IP.  The  National 
Science  Foundation  Network  (NSFNET)  in  1985  used  TCP/IP  over  T-1 
links;. this  represented  an  important  Government  commitment.  By 
1988  hardware/software  platforms  were  available  which  incorporated 
TCP/IP. 

In  1986,  the  Internet  Architecture  Board  (lAB)  created  the  Internet 
Engineering  Task  Force  (IETF)  and  the  Internet  Research  Task  Force 
(IRTF) . The  former  was  chartered  to  provide  near-term  solutions  to 
Internet  operational  problems  and  to  develop  near-term  enhancements 
for  the  Internet.  The  latter  group  was  asked  to  pursue  topics  of 
long-term  interest  that  carry  some  technical  risk.  The  IETF 
benefited  from  regional  network  and  NSF  interest  in  their 
activities. 
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Attendance  at  the  first  IETF  meetings  numbered  a few  individuals. 
Today  attendance  is  over  700.  Currently  the  Internet  is  estimated 
to  include  about  40,000  networks  and  20  million  users,  and  the 
number  of  networks  and  users  connected  is  growing  every  year.  In 
sum,  several  factors  were  key  to  the  explosive  growth  of  the 
Internet  Protocol  Suite:  (1)  DARPA  funded  the  academic  community  to 
carry  out  much  of  the  original  research.  This  developed  expertise 
and  stimulated  interest  in  these  protocols  among  the  creative 
members  of  this  community,  which,  in  turn,  stimulated  additional 
research  emd  development  work  not  funded  by  DlOtPA,  and  led  to 
expanded  usage  of  the  protocols  in  the  academic  world.,  (2)  DARPA 
funded  the  inclusion  of  the  Internet  Protocol  Suite  in  UNIX  4.1 
BSD,  (3)  Sun  Microsystems  included  the  Internet  Protocol  Suite 
source  code  in  its  Sun  Operating  System,  and  (4)  NSFNET  came  into 
existence. 

2. 1.1. 2 Specific  Process 

The  process  by  which  Internet  Protocol  Suite  (IPS)  standards  are 
developed  has  evolved  over  time  as  the  scope  and  importance  of  the 
IPS,  the  Internet  and  related  commercial  markets  have  grown.  In 
1992  the  IETF  process  for  approving  standards  became  more  formal; 
lAB  members  must  now  be  nominated  and  approved  according  to 
established  procedures.  IPS  standards  development  is  primarily  the 
responsibility  of  the  IETF.  The  IETF  consists  of  numerous  working 
groups  (WGs)  that  are  formed  to  address  specific,  narrowly  focused 
development  or  operational  issues  relating  to  the  Internet. 

The  primary  goal  of  most  IETF  working  groups  is  the  technical 
development  of  IPS  standards.  Individuals  interested  in  the 
content  and  progression  of  IPS  standards  attend  the  three  or  four 
IETF  meetings  that  are  held  annually  and  participate  in  the 
deliberations  of  the  working  groups.  All  documents  being  developed 
by  IETF  working  groups  are  required  to  be  available  on-line. 

While  the  IETF  working  groups  develop  the  technical  specifications, 
the  progression  of  these  documents  through  the  standards  process  is 
controlled  by  an  oversight  committee  called  the  Internet 
Engineering  Steering  Group  (lESG) . For  the  purposes  of  such 
oversight,  IETF  working  groups  are  organized  into  specific  subject 
areas.  Each  area  has  one,  or  more,  director (s)  who  together  with 
the  IETF  chairperson  comprise  the  lESG.  The  lESG  makes  all 
decisions  regarding  the  progression  of  specifications  through  the 
IPS  standards  process. 

The  IETF  forms  one  half  of  the  Internet  Society's  (ISOC)  standards 
and  research  infrastructure.  The  ISOC  is  a professional  society 
that  is  concerned  with  the  growth  and  evolution  of  the  worldwide 
Internet,  with  the  way  the  Internet  can  be  used,  and  with  the 
social,  political  and  technical  issues  that  arise  as  a result. 
Previously  IETF  attendance  was  mostly  by  the  research  and  academic 
community,  but  now  attendees  with  commercial  interests  predominate. 
Non-US  participation  in  IETF  meetings  is  growing  as  a percentage  of 
total  attendees,  but  non-US  participants  are  still  a minority  of 
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all  participants.  The  Internet  Research  Task  Force  (IRTF)  forms 
the  other  half  of  the  infrastructure  and  is  tasked  with  long-term 
research  issues  related  to  the  evolution  of  the  Internet.  The  lAB, 
which  reports  to  the  ISOC  board  of  trustees,  is  tasked  with  the 
broad  oversight  and  coordination  of  all  IETF  and  IRTF  activities. 

The  primary  means  of  Internet  standardization  is  through  requests 
for  comments  (RFCs) . RFCs  began  as  an  informal  means  of 
documenting  technical  information  for  the  original  ARPANET.  Today, 
the  RFC  mechanism  is  part  of  a formal  Internet  standards  process. 

2. 1.1. 3 Internet  Perspective 

There  are  still  several  issues  and  problems  regarding  the  Internet. 
There  is  no  central  Internet  "authority”.  Although  agreements 
exist  between  service  providers,  it  is  still  difficult  for  the  user 
to  determine  whom  to  contact  when  something  goes  wrong.  The  same 
informality  that  has  the  allowed  the  explosive  growth  of  the 
Internet  has  made  it  more  difficult  to  determine  responsibility  for 
its  operation. 

The  Internet  has  developed  in  a non-commercial  environment  into  the 
leading  major  international  non-regulated  network  of  value  added 
services.  Furthermore,  the  Internet  has  promoted  the 
implementation  of  de  facto  standards  intended  for  international 
recognition.  An  agreement  was  concluded  in  June  1994  between  the 
International  Organization  for  Standardization  (ISO)  (see  sec. 
2.2.1)  and  the  IETF  that  will  lead  to  some  mutual  recognition  of 
Internet  and  ISO  protocols  and  the  organization  of  joint 
activities. 

The  Internet  is  evolving  towards  providing  commercial  services  for 
the  general  public.  Participation  by  the  ARPA,  Defense 
Communications  Agency  (DCA) , NSF,  National  Aeronautics  and  Space 
Administration  (NASA)  and  other  government  agencies  has  been  an 
important  factor  in  the  development  of  the  Internet,  but  the 
involvement  of  these  government  agencies  is  declining.  The 
original  ARPANET  plan  did  not  include  application  services  such  as 
mail,  lists,  or  news.  People  who  wanted  these  services  developed 
them.  For  example,  the  User's  Network  (USENET)  has  developed  into 
a worldwide  distributed  conferencing  system. 

2.1.2  Architecture 

The  IPS  architecture  consists  of  four  layers;  (1)  the  Network 
Interface  (hardware)  Layer,  (2)  the  Internet  Layer,  (3)  the 
Transport  Layer,  and  (4)  the  Application  Layer.  Each  layer 
provides  service  to  the  layer  above.  The  function  of  the  Network 
Interface  Layer  is  the  transfer  of  data  frames  between  directly 
connected  machines,  to  support  the  internetworking  capability  of 
the  Internet  layer.  Sequencing  and  error  detection  may  be 
provided.  These  functions  can  be  provided  by  various  subnetwork 
technologies.  These  subnetwork  technologies  are  independent  of  the 
IPS  architecture  (as  well  as  other  architectures,  for  example. 
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OSI)  . The  IPS  must  be  mapped  onto  specific  subnetwork  services. 
Examples  of  subnetwork  technologies  are:  local  area  networks 
(LANs),  point-to-point  links,  X.25,  switched  multimegabit  data 
service  (SMDS) , frame  relay,  integrated  services  digital  network 
(ISDN),  and  asynchronous  transfer  mode  (ATM) /synchronous  optical 
network  transmission  (SONET) . 

The  function  of  the  Internet  Layer  is  to  provide  internetworking 
among  machines  not  directly  connected.  The  internetworking 
protocol  for  the  Internet  Layer  is  the  Internet  Protocol  (IP) ; the 
function  of  this  protocol  is  to  route  data  between  source  and 
destination  end  systems  on  the  same  network  or  different  networks, 
through  a series  of  intermediate  systems  if  necessary.  Routing 
protocols  may  be  intra-domain  or  inter-domain;  domains  may  be 
organized  along  administrative  or  technical  lines.  A network 
address  is  used  to  identify  the  destination  system. 

The  function  of  the  Transport  Layer  is  to  provide  end-to-end 
transfer  of  IP  datagrams  between  source  and  destination  machines. 
The  protocols  that  provide  this  capability  are  the  Transmission 
Control  Protocol  (TCP)  and  the  User  Datagram  Protocol  (UDP) . TCP 
is  a connection-oriented  reliable  transport  service,  and  UDP  is  an 
unreliable  connectionless  transport  service.  TCP  offers  a stream 
service  to  applications.  Flow  control,  congestion  control,  error 
detection,  framing,  and  demultiplexing  services  are  provided  by  the 
Transport  Layer. 

The  IPS  applications  are  remote  login  (TEINET) , file  transfer 
protocol  (FTP) , and  the  Simple  Mail  Transfer  Protocol  (SMTP) , 
These  applications  present  a data  stream  to  the  transport  service, 
and  provide  a customized  interface  to  the  applications  user.  All 
functions  at  this  layer  are  intrinsic  to  particular  applications. 
Services  offered  to  the  user  are  specific  to  individual  protocols. 

2.1.3  Services 

This  section  describes  the  current  services  provided  by  the 
Internet  Protocol  Suite  (IPS)  and  anticipates  those  services  which 
are  likely  to  be  provided  in  the  foreseeable  future.  To  the  extent 
possible,  there  will  be  an  assessment  of  marketplace  acceptance  of 
implementations  providing  these  services. 

2. 1.3.1  Application  Layer  Services 

2 . 1 . 3 . 1 . 1 Remote  Login 

The  IPS  virtual  terminal  protocol,  TEINET,  was  designed  with  scroll 
mode  terminals  in  mind,  although  some  page  mode  terminal  properties 
can  be  negotiated.  Scroll  mode  terminals  do  not  have  any  local 
editing  capability.  The  TELNET  protocol  is  concerned  with  setting 
up  and  manipulating  two  simplex  data  streams,  one  in  each 
direction. 

TELNET  allows  a user  to  connect  and  run  applications  on  a remote 
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computer.  To  initiate  a TELNET  session,  a user  first  identifies 
the  remote  host  with  an  Internet  address.  The  remote  system  then 
prompts  for  a username  and  a password  to  ensure  access  only  by 
authorized  users.  Once  connected,  a user  can  run  applications  on 
the  remote  host  just  as  if  connected  to  a local  host.  Once  the 
TELNET  session  begins,  applications  run  on  the  processor  of  the 
remote  computer,  not  on  the  local  system  that  initiated  the 
session. 

TELNET  offers  three  basic  services.  First,  it  defines  a network 
virtual  terminal  that  provides  an  interface  to  remote  systems 
around  which  client  programs  are  built.  Second,  it  includes  a 
mechanism  that  allows  the  client  and  server  to  negotiate  options 
and  it  provides  a set  of  standard  options  (e.g.,  an  option  controls 
whether  data  passed  across  the  connection  is  binary  or  ASCII  text) . 
Finally,  TELNET  treats  both  ends  of  the  connection  symmetrically. 
So,  instead  of  forcing  one  end  to  connect  to  a user's  terminal, 
TELNET  allows  either  end  of  the  connection  to  be  a program.  No 
additional  TELNET  services  are  currently  planned,  except,  possibly, 
TELNET  encryption. 

Most  vendors  who  market  the  UNIX  operating  system  include  the 
Internet  TELNET  as  part  of  the  operating  system.  For  this  reason, 
the  Internet  TELNET  application  is  widely  available.  Government 
agencies  and  universities  rely  on  the  Internet  and  TELNET  for 
remote  login.  Most  database  services  and  electronic  bulletin 
boards  use  IPS  TELNET  as  one  of  the  primary  access  methods. 

2. 1.3. 1.2  Mail 

The  IPS  electronic  mail  application  is  known  as  the  Simple  Mail 
Transfer  Protocol  (SMTP) . SMTP  is  implemented  in  accordance  with 
RFC--822  and  RFC-821.  RFC-822  defines  a commonly  implemented 
message  format  used  in  Internet  mail,  USENET,  BITNET,  and  other 
messaging  systems.  RFC-821  defines  the  protocol  necessary  to 
convey  that  format  between  systems. 

Communication  between  a client  and  server  consists  of  readable 
text.  Although  SMTP  rigidly  defines  the  command  format,  a 
transcript  of  interactions  between  a client  and  server  is  easily 
read  by  humans.  Once  communication  has  been  established,  the 
originator's  system  can  transmit  one  or  more  mail  messages, 
terminate  the  connection,  or  request  the  server  to  turn  roles  of 
sender  and  receiver  around  so  that  messages  can  flow  in  the 
opposite  direction.  The  recipient's  system  must  acknowledge  each 
message.  It  can  also  abort  the  entire  connection  or  abort  the 
current  message  transfer. 

The  SMTP  protocol  focuses  specifically  on  how  the  underlying  mail 
delivery  system  passes  messages  across  a link  from  one  machine  to 
another.  It  does  not  specify  how  the  mail  system  accepts  mail  from 
a user  or  how  the  user  interface  presents  the  user  with  incoming 
mail.  Also,  SMTP  does  not  specify  how  mail  is  stored  or  how 
frequently  the  mail  system  attempts  to  send  messages.  There  is  an 
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extended  SMTP  (RFCs  1425-28)  (not  widely  implemented) , that  allows 
a sending  Message  Transfer  Agent  (MTA)  to  determine  the 
capabilities  of  a prospective  receiver.  Once  it  is  clear  that  the 
receiver  is  capable,  the  sender  can  use  additional  extensions  to 
signal  such  parameters  as  the  length  and  type  of  message  to  be 
sent . 

RFG-822  was  initially  written  to  convey  ASCII  text.  The  Multi- 
media Internet  Mail  Extensions  (MIME)  standard  was  developed  to 
expand  the  message  format  to  include  non-ASCII  text  and  multi-media 
attachments.  MIME  provides  three  capabilities:  (1)  it  standardizes 
several  encoding  techniques  that  can  be  used  when  needed  to  render 
binary  data  into  a character  form,  (2)  it  provides  a tagging  scheme 
to  label  each  attachment  as  to  its  information  type,  and  (3)  it 
provides  for  marker  strings  that  allow  MIME -enabled  User  Agents 
(UAs)  to  determine  the  beginning  and  end  of  each  attachment. 

Most  vendors  marketing  the  UNIX  operating  system  include  SMTP  as 
part  of  the  operating  system.  For  this  reason,  SMTP  is  widely 
available  from  most  major  vendors  and  many  small  software  houses. 
Public  domain  versions  of  MIME  are  also  available.  Basic  Internet 
messaging  has  been  implemented  and  deployed  more  widely  than  any 
other  messaging  technology,  standardized  or  proprietary. 

PEM  (Privacy  Enhanced  Mail)  does  for  the  security  of  Internet  mail 
what  MIME  does  for  its  media  capabilities.  Like  MIME,  PEM  builds 
on  the  RFC  822  message  format  to  allow  users  to  encrypt  and 
digitally  sign  messages  so  as  to  guard  their  privacy,  authenticate 
their  origin,  and  prevent  their  modification.  PEM  has  not  been 
that  successful;  however,  because  (among  other  reasons)  it  is  not 
geared  for  a multilevel  security  environment. 

2. 1.3. 1.3  File  Access  and  Transfer 

The  IPS  File  Transfer  Protocol  (FTP)  is  a simple  user-oriented 
protocol  designed  to  transfer  files  between  remote  hosts.  FTP  uses 
the  IPS  TELNET  protocol  to  set  up  a connection  between  the  FTP  user 
and  server.  The  services  provided  by  FTP  are  login 
(USER, PASS, ACCT) , close  (QUIT),  transfer  of  entire  files  (GET, PUT) , 
and  a file  directory  capability.  A limited  number  of  file  types 
(e.g.,  ascii,  binary,  image)  can  be  transferred. 

FTP  allows  authorized  users  to  log  into  a remote  system,  identify 
themselves,  list  remote  directories,  copy  files  to  or  from  the 
remote  machine,  and  execute  a few  simple  commands  remotely  (e.g. , 
to  obtain  help  with  the  remote  machine  file  name  syntax)  . FTP 
understands  a few  basic  file  formats  and  can  convert  among  popular 
representations  (e.g.,  between  EBCDIC  and  ASCII  character  sets). 
Many  FTP  implementations  provide  statistics  on  transfer  rates  and 
diagnostic  aids  such  as  packet  tracing.  FTP  allows  a user  to 
access  multiple  systems  in  a single  "session".  Commercial 
implementations  of  FTP  are  widely  available  for  most  common 
computing  environments.  Public-domain  implementations  of  FTP  are 
readily  available  for  MS-DOS  and  UNIX  environments. 
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The  Network  File  System  (NFS),  developed  by  Sun  Microsystems, 
offers  the  ability  to  share  file  systems  among  computers  on  a 
TCP/IP  network.  FTP  transfers  individual  files  from  one  computer 
to  another.  NFS  takes  this  a step  further,  making  all  or  part  of 
the  file  system  of  a remote  computer  seem  like  it  is  resident  on  a 
local  computer. 

An  NFS  server  makes  part  of  its  file  structure  available  to  be 
shared  by  other  computers  on  the  network.  The  NFS  server  must 
include  security  features  to  ensure  that  only  authorized  computers 
gain  access  to  its  file  systems.  NFS  uses  the  User  Datagram 
Protocol  as  the  underlying  transport  mechanism.  An  NFS  client  can 
mount  the  file  system  of  a remote  host  on  a TCP/IP  network. 

Microcomputer-based  TCP/IP  products  often  do  not  include  NFS,  or 
offer  it  as  an  added-cost  option.  Some  may  offer  an  NFS  client, 
but  not  include  NFS  server  capabilities. 

2. 1.3. 1.4  Directory  Service 

In  the  traditional  IPS  environment,  directory  services  are  usually 
provided  by  one  of  three  basic  alternatives;  (a)  the  WHOIS  service 
currently  provided  under  the  InterNIC  Directory  and  Database 
Services  contract;  (b)  the  "Host  Table"  service  currently  provided 
under  the  InterNIC  contract;  and  (c)  the  "Domain  Name  System" 
(DNS) . 

The  WHOIS  database  system  accepts  simple  query  requests  and 
performs  a broad  or  constrained  search  of  the  WHOIS  databases  for 
the  requested  information.  Because  WHOIS  is  a centralized  database 
service,  it  does  not  scale  easily  to  serve  the  needs  of  a global 
user  community.  Problems  dealing  with  the  growth  in  size  and  use 
of  the  database  have  already  led  to  breaking  the  database  into 
several  physical  pieces  that  are  logically  integrated  using  ad  hoc 
methods . 

The  Host  Table  service,  like  WHOIS,  is  a centralized  query/ response 
system  hosted  on  an  InterNIC  server.  In  this  context,  access  is  by 
means  of  a local  application  program  which  establishes  a TCP 
connection  to  port  101  at  the  service  host.  Using  the  Hostname 
Server  Protocol,  the  NIC  Host  Table  service  accepts  simple  query 
requests,  performs  a search  of  the  Host  Table  for  related  entries, 
and  then  returns  the  related  records.  The  problems  associated  with 
Host  Table  service  mirror  those  of  WHOIS;  the  service  is  not 
scalable  to  the  needs  of  a global  network  infrastructure. 

Unlike  Host  Table  and  WHOIS,  the  DNS  is  a distributed  database 
system.  The  contents  of  the  database  can  be  viewed  from  a network 
global  perspective  as  being  allocated  among  many  servers.  A 
typical  DNS  Resolver  offers  the  following  three  functions:  (1) 
translation  of  a host  name  to  the  corresponding  host  address,  (2) 
translation  of  a host  address  to  the  corresponding  host  name,  and 
(3)  general  lookup  of  host  information. 
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The  DNS  translates  an  IP  address  in  its  registered  canonical  form 
to  the  dotted  decimal  notation;  for  example, 
"boland@snad.ncsl.nist.gov"  may  be  translated  to  "129.6.55.1". 
People  remember  and  manipulate  names  much  better  than  numbers,  but 
low-level  TCP/IP  programs  deal  only  with  numerical  addresses.  It 
is  common  practice  to  assign  each  computer  on  a network  a name  that 
consists  of  a unique  machine  name  prepended  to  the  domains 
associated  with  the  network.  TCP/IP  networks  almost  always  include 
a "nameserver"  computer  that  performs  DNS.  It  constantly  listens 
for  requests  for  its  services. 

The  DNS  is  a highly  specialized  database  system.  Because  it  is 
specialized  to  handle  a small  number  of  record  types  and  has 
limited  search  capability,  it  is  able  to  provide  high  performance. 
However,  specialization  also  limits  its  applicability.  (In 
general,  DNS  functionality  is  relatively  difficult  to  extend  when 
compared  to  the  flexibility  inherent  in  the  OSI  Directory 
architecture.)  A digital  signature  service  is  being  planned  for 
DNS  in  the  future. 

Products  needed  to  access  and  use  the  WHOIS  and  Host  Table  services 
are  widely  available.  Likewise,  DNS  server  and  resolver  products 
are  widely  available;  a public  domain  implementation  is  also 
available.  The  WHOIS  service  is  widely  used  by  the  IPS  community. 
The  Host  Table  service,  despite  its  problems,  continues  to  be  used 
by  legacy  applications  that  have  not  been  converted  to  use  DNS. 
The  DNS  is  widely  deployed  throughout  the  IPS  community  and  is  used 
extensively  by  some  implementations  of  Internet  electronic  mail . 
The  DNS  distributed  database  contains  information  to  locate  the 
appropriate  server  that  could  find  the  IP  addresses  for  any  system 
connected  to  it. 

The  OSI  Directory  Service  is  being  seriously  considered  as  a 
solution  due  to  limitations  in  the  current  alternatives.  For 
example,  the  combined  limitations  of  the  traditional  directory 
services  for  Internet  Protocol  Suite  users  have  led  to  extensive 
pilot  programs  throughout  the  world  that  are  experimenting  with  the 
use  of  the  OSI  Directory  Service  to  provide  a more  flexible  and 
scalable  directory. 

2. 1.3. 1.5  Information  Retrieval 

The  IPS  supports  user-defined  protocols  to  access  information 
available  via  the  Internet;  there  are  no  direct  OSI  counterparts  to 
these  protocols.  The  Internet  has  an  enormous  volume  of 
information  available  (such  as  anonymous  FTP  archives  and 
databases) . There  are  a number  of  resource  discovery  tools  being 
designed  and  tested  on  the  Internet,  including  Archie,  Gopher, 
Wide  Area  Information  Service  (WAIS) , and  Mosaic.  The  placement  of 
source  code  at  low  cost  into  creative  hands  has  led  to  the 
development  of  widely-used  functionality  totally  independent  of  the 
Internet  standards  process. 

The  primary  purpose  of  Archie  is  to  provide  a convenient  way  for 
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users  to  browse  the  anonymous  FTP  archives  available  throughout  the 
Internet.  The  shortcomings  of  Archie  include  replication  of 
information  and  nonoptimal  query  keys.  The  original  implementation 
was  done  at  McGill  University  in  Montreal,  Canada. 

Gopher  was  initially  intended  as  a campus-wide  information  system 
for  the  University  of  Minnesota.  Thus,  the  emphasis  is  on 
providing  a convenient  structure  for  information  of  the  scope  and 
size  needed  by  a campus  community.  Since  not  all  of  the 
information  needed  by  a user  community  is  typically  stored  on  on- 
campus  systems,  the  design  of  Gopher  gives  the  user  convenient 
access  to  the  information  without  the  user  having  to  know  precisely 
where  it  resides.  The  potential  drawback  to  Gopher  is  a lack  of 
scalability.  To  ameliorate  this  problem,  a specialized  index- 
server  has  been  developed  for  Gopher  called  Veronica.  Veronica 
collects  lists  of  Gopher  items  from  Gopher  servers  and  allows  users 
to  perform  keyword  searches  on  the  lists. 

The  WAIS  is  a full-text  search  and  retrieval  system.  It  allows 
users  to  search  and  retrieve  information  from  indexed  databases. 
The  information  can  include  text,  formatted  documents,  pictures, 
spreadsheets,  graphics,  sound,  and  video. 

The  World  Wide  Web  (WWW)  is  a collection  of  information  sources, 
interlinked  using  a hypertext  markup  language  (HTML) . While  Gopher 
tends  to  be  text -based  and  hierarchical,  the  Web  relies  more  on 
hypertext  and  multimedia  presentations.  Web  servers  implement  a 
protocol  called  Hypertext  Transfer  Protocol  (HTTP)  and  use 
documents  stored  in  HTML  format.  One  can  traverse  the  WWW  by 
following  the  links  established  between  documents.  Mosaic  and 
Netscape  are  user  interfaces  for  providing  such  traversal. 

2. 1.3. 2 Transport/Netvork  Layer  Services 

The  IPS  transport  service  is  provided  by  the  Transmission  Control 
Protocol  (TCP)  and  User  Datagram  Protocol  (UDP) . The  service 
provided  is  transmission  of  IP  packets  between  end  systems  on  the 
same  network  or  different  subnetworks.  TCP  provides  a reliable 
end-to-end  packet  delivery  mechanism,  and  UDP  provides  an 
unreliable  packet  delivery  mechanism.  The  IPS  network  layer 
service  is  the  Internet  Protocol  (IP) . 

2. 1.3. 3 Network  Mamagement 

The  network  management  application  services  in  the  IPS  are  provided 
by  the  Simple  Network  Management  Protocol  (SNMP) ; SNMP  comprises 
three  RFCs  (RFC  1155  - Structure  and  Identification  of  Management 
Information  for  TCP/IP  Networks,  RFC  1157  - Simple  Network 
Management  Protocol,  and  RFC  1213  - Management  Information  Base  for 
Network  Management  of  TCP/IP-based  Internets) . 

The  IPS  Structure  of  Management  Information  (SMI)  standard  provides 
a methodology  for  abstractly  defining  managed  objects,  which  in 
this  model  are  variables  that  represent  atomic  data  elements. 
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These  managed  objects  are  collected  into  a database,  called  the 
Management  Information  Base  (MIB) , which  defines  the  set  of 
variables  that  SNMP  servers  maintain  as  well  as  the  semantics  of 
each  variable.  MIB  variables  record  the  status  of  each  connected 
network,  traffic  statistics,  counts  of  errors  encountered,  and  the 
current  contents  of  internal  data  structures  such  as  the  machine's 
IP  routing  table.  Each  managed  object  contains  a name,  a type 
syntax,  access  information,  and  status.  The  Internet  SMI  allows 
MIB  variables  to  be  collected  into  lists  and  tables. 

SNMP  helps  network  managers  locate  and  correct  problems  in  a TCP/IP 
Internet.  Managers  invoke  an  SNMP  client  on  their  local  computer 
and  use  the  client  to  contact  one  or  more  remote  SNMP  servers. 
SNMP  uses  a fetch-store  paradigm  in  which  each  server  maintains  a 
set  of  conceptual  variables  that  include  simple  statistics,  such  as 
a count  of  packets  received.  SNMP  messages  either  specify  that  the 
server  should  fetch  values  from  variables  or  store  values  in 
variables,  and  the  server  translates  the  requests  to  equivalent 
operations  on  local  data  structures.  SNMP  defines  both  the  syntax 
and  meaning  of  the  messages  that  clients  and  servers  exchange. 

An  example  of  SNMP  operation  might  involve  storing  the  time  a 
system  has  been  operational.  Many  systems  simply  record  the  time 
at  which  the  system  started,  and  compute  the  time  that  the  system 
has  been  operating  by  subtracting  the  startup  time  from  the  current 
time.  Thus,  SNMP  software  can  simulate  a MIB  "variable"  that 
contains  the  time  since  last  startup.  It  performs  the  computation 
whenever  a request  arrives  to  read  a value  from  the  MIB  variable, 
and  the  remote  site  remains  unaware  of  the  computation. 

The  theory  of  operation  of  IPS  network  management  is  less  complex 
than  that  of  OSI  network  management  (see  sec.  2. 2. 3. 2).  For 
example,  data  relating  to  managed  objects  must  be  requested  by  the 
manager  - data  is  not  automatically  provided.  IPS  network 
management  uses  polling  from  the  manager  to  the  agent  to  gather 
information,  whereas  OSI  network  management  uses  a notification 
mechanism  from  the  agent  to  the  manager.  However,  by  establishing 
an  appropriate  time  interval  between  information  transfer,  IPS 
network  management  can  simulate  OSI  network  management. 

Currently,  SNMP  Version  1 (vl)  seems  to  be  the  protocol  of  choice 
for  managing  the  resources  associated  with  TCP/IP  networks.  SNMPvl 
has  been  widely  implemented  by  many  vendors;  the  implementation 
cost  has  been  relatively  low  due  to  the  simple  design  of  the 
protocol  and  the  MIB.  However,  SNMPvl  may  not  provide  sufficient 
security,  does  not  support  bulk  data  transfer,  is  not  robust,  and 
does  not  provide  sufficient  scalability  (limited  number  of  agent 
devices  per  management  system) . Recently,  a new  version  of  SNMP, 
SNMPv2,  is  making  its  way  through  the  Internet  standards  process. 
This  new  version  promises  enhanced  management  capabilities, 
including  Secure  SNMP  and  support  of  bulk  data  transfer.  SNMP  v2 
is  not  likely  to  be  widely  implemented  or  deployed  in  the  next 
several  years  because  of  its  cost  and  transition  issues  from 
SNMPvl.  SNMPv2  may  provide  more  security  than  is  needed  by  most 
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users. 

2. 1.3. 4 Security 

Network  security  services  for  the  IPS  include  authentication, 
access  control,  encryption,  and  data  integrity.  Security  services 
are  provided  at  the  Internet  and  Application  Layers.  A protocol  is 
being  defined  to  provide  security  services  for  IP;  this  protocol  is 
called  IPSEC  (IP  Security  Protocol) ; functionally  it  is  the  same  as 
the  OSI  Network  Layer  Security  Protocol  (see  sec.  2. 2. 3. 3)  but 
employs  different  mechanisms.  IPSEC  provides  all  of  the  security 
services  defined  above;  it  is  to  be  used  if  a common  level  of 
security  is  desired  among  all  applications.  Also,  it  only  provides 
security  between  adjacent  systems;  it  does  not  provide  true  end-to- 
end  (or  application)  security. 

2. 1.3. 5 Application  Progreun  Interfaces 

There  are  no  application  program  interfaces  that  are  currently 
widely  used  by  the  IPS. 

2. 1.3. 6 Conformamce/Interoperability  Testing 

Testing  on  the  Internet  is  ad-hoc  and  informal . There  are  no 
specific  codified  interoperability  criteria,  so  the  level  of 
interworking  is  not  documented  anywhere.  Sometimes  a "TCP/IP 
bakeoff"  (interoperability  testing  tournament)  occurs,  where 
implementations  are  tested  against  each  other,  using  informal 
accumulations  of  tests.  The  usual  result  of  such  a bakeoff  is  a 
media  event,  announcing  the  interoperable  participants.  There  is 
no  publicly  available  formal  record  of  the  level  of  testing 
conducted . 

2.2  Open  Systems  Interconnection  (OSI)  Protocol  Suite 
2.2.1  OSI  Background 

The  objective  of  the  early  developers  of  the  Open  Systems 
Interconnection  (OSI)  standards  was  to  provide  an  internationally 
recognized  method  for  providing  interoperability  among 
heterogeneous  computer  systems.  When  the  decision  was  made  to 
develop  these  standards  in  the  late  1970 's,  the  first  step  was  to 
develop  an  OSI  Reference  Model.  The  Reference  Model  partitioned 
the  communication  functions  into  seven  layers.  Each  layer  provided 
a service  to  the  layer  above  while  shielding  the  upper  layer  from 
the  details  of  how  the  service  was  actually  implemented.  The 
Reference  Model  allowed  the  concurrent  development  of  standards  at 
the  different  layers;  for  example,  standards  for  Message  Handling 
Systems  at  the  Application  Layer  (layer  7)  could  be  and  were 
developed  concurrently  with  the  Transport  and  Network  Layer 
standards  at  layers  4 and  3 respectively. 

OSI  standards  were  developed  in  Joint  Technical  Committee  1 (JTCl) 
of  the  International  Organization  for  Standardization  (ISO)/ 
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International  Electrotechnical  Commission  (lEC) , as  well  as  by  the 
International  Telecommunications  Union  - Telecommunications 
Standardization  Sector  (ITU-T)  (formerly  CCITT) . The  American 
National  Standards  Institute  (ANSI)  is  the  ISO/IEC  member 
representing  the  United  States.  The  outputs  of  the  OSI  ISO/IEC 
standardization  process  are  classified  as  either  ISO/IEC 
international  standards  or  technical  reports. 

The  ITU-T  is  an  international  organization  whose  aim  is  the 
production  of  standards  for  international  interworking  of  telephone 
and  other  telecommunications  systems.  The  ITU-T  has  adopted  a 
four-year  work  cycle.  ITU-T  Recommendations  are  voted  on  and,  if 
approved,  published  at  the  end  of  this  four-year  cycle.  The  State 
Department  is  the  US  member  to  ITU-T.  There  is  currently  an 
Internet  Society  (ISOC)-ITU  reciprocity  agreement. 

The  TTU“T  differs  from  the  ISO/IEC  in  that  the  former  has  full 
members  that  are  usually  the  telecommunication  carriers  for  public 
data  networks  of  each  nation,  whereas  ISO/IEC  membership  is  open 
only  to  national  standards  organizations.  The  ISO/IEC  may 
cooperate  with  the  ITU-T  in  the  development  of  joint  standards 
(such  as  Directory  Services) . 

The  need  to  achieve  consensus  has  prevented  the  international 
standards  organizations  from  restricting  options  (e.g. , there  are 
five  allowable  classes  of  Transport) , Low-level  decisions,  such  as 
allowable  values  of  specific  parameters  (e.g,,  maximum  length  of 
message)  are  not  made.  Consequently,  in  addition  to  base  standard 
specifications,  the  OSI  standards  process  contains  an  additional 
level  of  standardization  known  as  functional  standards.  Functional 
standards,  also  known  as  profiles,  contain  selections  of  specific 
OSI  standards  along  with  additional  refinements  (e.g.,  selection  of 
protocol  options , specification  of  parameter  values)  appropriate 
for  a particular  user  community.  Open,  public  regional  workshops 
around  the  world  develop  functional  standards,  and  harmonize  these 
standards  where  differences  occur. 

The  international  OSI  standards  process  is  slow;  it  may  take  five 
years  or  more  from  the  time  a proposed  work  item  is  submitted  to 
the  time  it  is  standardized.  There  is  a seemingly  endless  round  of 
ballots  and  ballot  resolution  meetings.  Regular  standards  meetings 
are  held  relatively  infrequently  and  the  pace  of  change  is 
painfully  slow.  The  ballot  procedures  themselves  are  unnecessarily 
complex  and  slow  progress.  The  additional  time  required  by 
regional  workshops  to  develop  functional  profiles  also  delays  the 
implementation  of  products  based  on  these  standards. 

The  need  to  gain  concurrence  caused  OSI  standards  to  be  too 
complex.  Workshops  had  to  determine  what  subset  of  services  to 
implement,  and  there  were  no  concurrent  implementations  to  test 
workability  of  standards.  The  complexity  of  OSI  standards 
increased  the  cost  of  the  standards  to  develop. 

Information  relating  to  the  OSI  standards  in  progress  was  riot 
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easily  obtainable.  On-line  distribution  was  not  available,  and 
only  a few  centers  were  authorized  to  sell  paper  copies  of  the 
standards.  The  documents  were  not  generally  available  in 
electronic  form. 

The  ISO/IEC  JTCl  has  a scope  of  standards  development  similar  to 
that  of  the  IETF.  IETF  working  groups  are  similar  to  specific 
technical  projects  within  ISO/IEC  working  groups;  however,  in 
comparing  the  review  and  approval  process,  there  are  several 
differences.  The  ISO/IEC/ANSI  process  employs  a consistent 
mechanism  of  explicit  voting  by  member  organizations.  The  IETF 
process  employs  oversight  committees  to  make  all  final  standards 
decisions. 

Other  differences  are  cultural.  In  order  to  have  a "reality  check" 
on  the  standards  being  developed,  the  IETF  develops  implementations 
of  the  standards.  The  lessons  learned  in  implementing  the 
standards  causes  vendors  to  make  modifications  at  an  early  date. 
The  failure  of  the  OSI  community  to  develop  implementations  in 
parallel  with  standards  has  led  to  incompletely  specified  standards 
despite  their  complexity.  The  IETF  interests  are  overwhelmingly 
dominated  by  North  American  concerns.  A focused  market  means  that 
in  the  IETF,  because  participation  is  predominately  North  American, 
fewer  interests  have  to  be  satisfied  in  producing  the  standards. 
The  OSI  community  is  more  diverse  than  that  of  the  IETF.  The  lack 
of  common  interests  means  that  there  may  be  less  cooperation  in  the 
OSI  world. 

Both  OSI  and  IETF  participants  are  recognizing  both  the 
shortcomings  of  their  respective  processes  and  the  benefits  of 
collaboration,  when  appropriate.  For  example,  the  IETF  is  seeking 
to  get  more  international  participation  in  its  activities.  The 
IETF  is  also  seeking  to  formalize  its  process  to  a greater  extent, 
and  is  working  with  the  OSI  community  to  determine  any  basis  for 
future  collaboration.  OSI  organizations  are  now  making  their 
documentation  more  publicly  available,  and  are  also  seeking  a basis 
for  future  collaboration. 

2.2.2  Architecture 

2. 2. 2.1  General  Description 

The  OSI  layers  are  as  follows;  (1)  Physical  Layer,  (2)  Data  Link 
Layer,  (3)  Network  layer,  (4)  Transport  Layer,  (5)  Session  Layer, 
(6)  Presentation  Layer,  and  (7)  Application  Layer.  Each  layer 
provides  services  to  the  layer  immediately  above.  Although  the 
generic  service  descriptions  are  specified,  implementation 
considerations  are  not. 

The  Physical  Layer  is  concerned  with  transmitting  raw  bits  over  a 
communication  channel;  that  is,  when  one  system  sends  a 1 bit,  it 
is  received  by  the  adjacent  system  as  a 1 bit,  not  a 0 bit.  The 
main  task  of  the  Data  Link  Layer  is  to  take  a raw  transmission 
facility  and  transform  it  into  a line  that  appears  free  of 
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transmission  errors  to  the  Network  Layer.  It  accomplishes  this 
task  by  having  the  sender  break  the  input  data  up  into  data  frames , 
transmit  the  frames  sequentially,  and  process  the  acknowledgement 
frames  sent  back  by  the  receiver. 

Layer  (3)  is  the  Network  Layer , which  routes  data  between  end 
systems  on  the  same  or  different  networks.  OSI  includes  both  a 
connection-oriented  network  service  (CONS)  and  connectionless 
network  protocol  (CLNP) . "Connection-oriented"  involves  setting  up 
a predefined  link  before  user  data  is  sent;  a link  is  in  effect  for 
the  life  of  the  connection  (analogy:  telephone  conversation) . 
Connectionless  packets  may  travel  different  paths  to  the 
destination  (analogy:  postal  letter) . 

The  Transport  Layer  provides  for  the  end-to-end  transfer  of  data 
packets  between  end  systems.  There  is  both  a connection-oriented 
service  and  a connectionless  service.  There  are  five  classes  of 
connection-oriented  transport  service  that  assume  varying  levels  of 
Network  Layer  services. 

The  Session  Layer  (layer  5)  allows  cooperating  application  entities 
to  organize  and  synchronize  conversation  and  to  manage  data 
exchange.  Session  services  include  dialogue  control  and  token 
management . 

The  Presentation  Layer  (layer  6)  specifies  or,  optionally, 
negotiates  the  way  information  is  represented  for  exchange  by 
application  entities.  The  Presentation  Layer  is  concerned  only 
with  the  syntax  of  the  transferred  data. 

The  Application  Layer  (layer  7)  allows  for  protocols  and  services 
required  by  particular  user-designed  application  processes. 
Functions  satisfying  particular  user  requirements  and  application 
service  elements  that  can  be  used  by  more  than  one  application  are 
contained  in  this  layer. 

2 . 2 . 2 . 2 OSI-IPS  Architectural  Comparison 

Although  the  OSI  and  IPS  Transport  and  Network  layers  map  one  for 
one,  the  functions  of  OSI  layers  5,  6 and  7 are  bundled  into  the 
IPS  Application  Layer.  At  the  Transport  Layer  the  IPS  has  a single 
protocol  for  providing  all  transport  services;  this  protocol 
corresponds  closely  to  OSI  Transport  Class  4 (TP4) . At  the  network 
layer  the  IPS  provides  a single  internetworking  protocol  (IP)  ; this 
protocol  provides  nearly  identical  functionality  to  OSI  CLNP, 
although  different  routing  protocols  and  address  structures  are 
used  in  support  of  each.  These  similarities  mean  that  OSI 
applications  can,  with  minor  modification,  use  the  TCP/IP 
infrastructure,  and  IPS  applications  can,  with  minor  modification, 
use  an  OSI  infrastructure. 

IPS  and  OSI  use  different  forms  of  network  addresses;  these  address 
forms  have  implications  in  the  behavior  of  OSI  and  IPS  routing 
protocols.  The  traditional  IPS  address  is  composed  of  four 
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numerics,  separated  by  delimiters  (dots) ; the  first  portion  of  the 
address  (one  to  three  numerics)  is  a network  identifier,  and  the 
second  portion  (one  to  three  numerics)  is  a host  identifier.  The 
n\imber  of  numerics  to  allocate  to  the  network  identifier  portion 
and  number  to  allocate  to  the  host  identifier  portion  depends  upon 
the  IPS  address's  class,  but  the  total  of  the  two  numbers  must  add 
up  to  four.  There  is  a shortage  of  Internet  address  space  because 
of  the  inefficient  assignment  of  IP  addresses  in  the  past  coupled 
with  the  increased  demand  for  those  addresses  due  to  the  many  new 
systems  being  attached  to  the  Internet.  A new  version  of  IP,  IPv6, 
that  is  currently  under  development,  will  provide  a larger  address 
space,  and  routing  aggregation  techniques  (such  as  Classless 
Interdomain  Routing  (CIDR) ) , as  well  as  more  efficient  assignment 
of  addresses.  OSI  address  space  depletion  has  never  occurred 
because  there  is  more  address  space,  the  method  of  address 
assignment  makes  more  efficient  use  of  this  space,  and  fewer  OSI 
addresses  have  been  assigned. 


2.2.3  Services 

This  section  describes  the  current  services  provided  by  the  OSI 
protocol  suite  and  anticipates  those  services  which  are  likely  to 
be  provided  in  the  foreseeable  future.  To  the  extent  possible, 
there  will  be  an  assessment  of  marketplace  acceptance  of 
implementations  providing  current  services. 

2. 2. 3.1  Application  Layer  Services 

2. 2. 3. 1.1  Mail 

The  OSI  electronic  mail  service  is  specified  in  the  ITU-T  X.400 
Series  of  Recommendations  for  Message  Handling  Systems  [REF  1] . 
The  original  recommendations  were  first  issued  by  the  ITU-T,  then 
known  as  the  CCITT,  in  1984.  A major  revision  to  those 
recommendations  was  issued  in  1988.  The  functional  model  developed 
in  the  1984  Recommendations  consisted  of  two  major  components  - The 
Message  Transfer  System  (MTS)  and  cooperating  User  Agents  (UAs) . 
The  MTS  is  composed  of  a series  of  Message  Transfer  Agents  (MTAs) 
that  are  responsible  for  relaying  the  message  from  the  originator's 
UA  to  the  recipients  UA.  The  message  may  be  routed  through 
intermediate  MTAs  that  can  perform  Application  Layer  routing  based 
on  address  information  contained  in  the  message.  The  originator's 
MTA,  the  recipients'  MTA  and  the  intermediate  MTAs  may  be  managed 
by  different  organizations  or  administrations.  An  administration 
is  either  a country's  Postal  Telephone  and  Telegraph  (PTT)  service 
(in  most  countries,  there  is  only  one  PTT)  or,  in  the  United 
States,  a common  carrier  recognized  by  the  ITU-T,  such  as  Sprint  or 
AT&T. 

The  MTS  is  responsible  for  accepting  the  message  from  the 
originator's  User  Agent  and  delivering  the  message  to  the  User 
Agents  of  all  recipients  addressed  in  the  message.  The 
originator's  User  Agent  supplies  to  the  MTS  the  message  content. 
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the  address (es)  of  the  message  recipients,  and  the  MTS  services 
that  are  being  requested.  In  addition  to  message  submission  and 
delivery  interaction.  User  Agents  have  many  functions  that  are 
outside  the  realm  of  standardization.  The  originator's  User  Agent 
assists  in  the  creation  and  editing  of  a message;  the  recipients' 
User  Agent (s)  can  use  certain  fields  in  the  message  to  control  the 
way  that  the  message  is  presented  to  the  recipient.  Only  the 
message  submission  and  delivery  interaction  with  the  local  MTA 
needs  to  be  standardized.  The  functional  model  allows  for 
different  types  of  User  Agents  to  communicate  with  each  other.  As 
long  as  the  recipient's  User  Agent  can  interpret  the  data  sent  by 
the  originator's  User  Agent,  meaningful  communication  is  possible. 
The  Message  Transfer  System  does  not  examine  the  message  content 
unless  a content  conversion  service  is  requested.  Although  many 
types  of  User  Agents  can  potentially  use  the  Message  Transfer 
Service,  a common  use  of  the  MTS  is  to  send  a message  from  an 
originator  to  one  or  more  recipients.  For  that  reason,  the  ITU-T 
standardized  an  Interpersonal  Messaging  User  Agent  in  the  1984 
X.400  Series  of  Recommendations.  The  1988  X.400  Series  of 
Recommendations  [REF  2]  expanded  the  model  that  was  developed  for 
the  1984  X.400  Recommendations.  The  1988  Recommendations 
recognized  that  some  User  Agents,  may  not  have  all  the 
functionality  and  storage  capacity  that  was  assumed  by  the  1984 
Recommendations.  For  example,  most  LAN  E-mail  systems  operate 
according  to  a client-server  paradigm  in  which  the  client,  a simple 
User  Agent,  sends  messages  to  and  fetches  messages  from  an 
intermediary  system  on  the  LAN  which  functions  as  a Message  Store 
and  provides  the  interface  to  the  outside  world.  The  ITU-T, 
recognizing  this,  standardized  a protocol  for  a Message  Store  to 
communicate  with  a remote  Message  Transfer  Agent  and  also  a 
protocol  for  a simple  User  Agent  to  communicate  with  a remote 
Message  Store.  In  practice;  however,  the  protocol  used  between  the 
User  Agent  and  Message  Store  is  almost  always  proprietary. 

Additional  services  were  also  incorporated  into  the  1988  X.40d 
Recommendations.  Security  services  were  added  which  enable  the 
various  components  of  the  Message  Handling  System  to  verify  the 
origin  of  messages  and  the  integrity  of  the  content  as  well  as 
prevent  unauthorized  disclosure  of  the  message  content.  These 
services  can  be  provided  within  the  Message  Transfer  System  or  by 
the  User  Agent  and/or  Message  Store  in  such  a way  as  to  be 
transparent  to  the  Message  Transfer  System.  The  1988  X.400 
Recommendations  provide  for  the  capability  of  interacting  with  an 
implementation  of  the  X.500  Directory  Service,  including  the 
ability  to  expand  a Distribution  List  contained  in  a message 
enroute  to  its  destinations.  The  1988  X.400  Recommendations 
provide  for  the  ability  to  interact  with  a Physical  Delivery  Access 
Unit  which  would  serve  as  a bridge  between  X.400  and  other  delivery 
mechanisms,  enabling  X.400  messages  to  be  routed  to  a remote  system 
and  allowing  final  delivery  to  be  made;  for  example,  by  the  postal 
service.  X.400  implementations  have  been  upgraded  to  provide  an 
interface  with  X.500  Directory  Service  implementations.  The  other 
services  included  in  the  1988  X.400  Recommendations  have,  for  the 
most  part,  not  been  implemented  and  will  not  be  implemented  unless 
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there  is  sufficient  user  demand. 

There  was  a growing  awareness  in  the  messaging  community  that  the 
X.400  Message  Transfer  Service  could  be  used  to  provide  the 
computer-to-computer  transfer  of  order  forms,  invoices, 
authorizations  for  payment  and  other  business  transactions.  This 
transfer  of  structured  business  data  is  called  Electronic  Data 
interchange  (EDI)  . Even  though  many  of  the  most  commonly  used  data 
forms  are  standardized  by  the  ANSI  Accredited  Standards  Committee 
X12  and  UN/EDIFACT  committees,  EDI  messaging  is  structured  so  that 
any  EDI  format,  including  privately  defined  data  forms,  can  be 
conveyed  by  the  X.400  Message  Transfer  Service. 

A user  that  wishes  to  use  the  X.400  Message  Transfer  Service  to 
send  an  EDI  transaction  has  different  requirements  from  a user  that 
wants  to  send  an  interpersonal  message.  For  example,  when  an  EDI 
transaction  is  sent  authorizing  payment  of  funds,  it  is  important 
that  the  recipient  know  that  the  message  was  sent  by  the  originator 
and  that  the  amount  of  funds  authorized  to  be  deducted  from  an 
account  has  not  been  tampered  with.  It  is  also  important  that  the 
originator  know  that  the  recipient  has  received  the  message  intact. 
In'  1991,  the  ITU-T  standardized  an  EDI  User  Agent  [REF  3]  that 
provides  the  services  required  by  EDI  messaging  users.  The 
security  services  specified  in  the  1988  X.400  Recommendations  were 
critical  for  meeting  these  requirements. 

2 .2. 3. 1.2  File  Access 

The  OSI  file  transfer  application  is  known  as  File  Transfer, 
Access,  and  Management  (FTAM)  [REF  4].  FTAM  allows  the  user  to 
transfer  a complete  file  or  a specified  portion  of  a file  (down  to 
record-level  access) . The  file  formats  allowed  are  numerous,  from 
a simple  text  file  to  indexed  sequential  files;  the  file  characters 
may  be  ASCII  text,  integer,  floating  point,  or  Kanji  characters 
(among  other  choices).  An  example  is:  read  the  233rd  record  of  a 
large  file  directly,  update  it,  and  write  it  back  directly.  Users 
can  remotely  modify  filename,  file  size  allowed,  and  other 
attributes.  Users  can  specify  access  control  on  particular  records 
of  files,  to  prevent  others  from  accessing  those  records.  Users 
can  easily  create  or  delete  files  remotely;  a number  of  types  of 
file  transfer  are  possible.  Users  can  recover  from  errors  in 
sending  a long  file  without  having  to  retransmit  the  entire  file. 
FTP  can  only  transmit  complete  files,  with  a limited  number  of 
formats.  With  FTP,  however,  users  can  remotely  create  or  delete 
directories. 

Most  current  FTAM  products  only  implement  complete  file  transfer 
(the  same  functionality  provided  by  FTP)  and  a limited  file 
management  capability.  Some  products  support  FTAM  gateways  to  FTP 
and  other  file  transfer  applications.  There  are  not  many  FTAM 
products  in  existence,  because  users  have  not  demanded  the 
additional  features  that  FTAM  provides  (e.g.,  record-level  access) 
that  are  not  provided  by  FTP.  No  additional  features  are 
anticipated  for  the  FTAM  standard. 
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Application  gateways  have  been  developed  to  allow  the  FTAM  and  FTP 
protocols  to  interoperate;  these  gateways  have  not  been  widely 
available.  RFC  1415  provides  a technical  specification  of  a FTAM- 
FTP  gateway.  The  FTAM  service  available  through  such  an 
application  gateway  is  a subset  of  the  full  FTAM  functionality. 

2. 2. 3. 1.3  Terminal  Emulation 

The  OSI  virtual  terminal  (VT)  application  [REF  5]  provides 
mechanisms  to  effectively  insulate  application  processes  from  the 
specific  characteristics  of  the  terminals  with  which  they 
communicate.  This  allows  terminals  to  access  applications  running 
on  a variety  of  systems,  and  vice  versa,  regardless  of  the  supplier 
of  the  terminal  or  host  system.  The  ultimate  goal  of  a virtual 
terminal  (VT)  application  is  that  terminals,  regardless  of  model  or 
design,  should  be  able  to  access  application  programs  resident  on 
either  a local  or  remote  system.  For  example,  a VTIOO  terminal  can 
login  to  two  different  computers  simultaneously  that  are  not  VT- 
100“compatible.  Similarly,  any  application  program  should  be  able 
to  communicate  with  any  terminal,  regardless  of  its  model  or  design 
and  regardless  of  whether  it  is  resident  on  the  same  or  a different 
system.  The  VT  standard  does  this  by  defining  a series  of  generic 
terminal  classes,  or  screen  representations,  to  which  real 
terminals  map  their  information. 

Several  VT  profiles  have  been  defined,  supporting  several  screen 
formats.  One  such  profile  (TELNET)  supports  a simple  line  at  a 
time  or  character  at  a time  dialogue.  The  transparent  profile 
supports  the  exchange  of  uninterpreted  sequences  of  characters. 
This  provides  the  ability  to  control  terminals  directly  through  the 
use  of  embedded  control  characters  and  escape  sequences.  The  forms 
profile  supports  forms-based  applications  that  provide  local  entry 
and  validation  of  data  by  the  terminal  system. 

Deployment  of  OSI  virtual  terminal  products  is  not  widespread 
today,  because  the  protocol  is  complex  and  users  have  not  required 
the  additional  functionality  provided  by  the  VT  application.  No 
further  extensions  are  planned  to  the  VT  standard.  Although  a 
VT/TELNET  gateway  is  technically  feasible,  it  has  not  been  in 
demand.  Although  the  VT  TELNET  profile  is  similar  in  functionality 
to  IPS  TELNET,  usage  of  IPS  TELNET  vastly  predominates. 

2 .2. 3 ^1.4  Transaction  Processing 

The  OSI  Transaction  Processing  (TP)  application  [REF  6]  allows 
users  to  perform  multiple  operations  as  an  atomic,  single, 
committed  action.  If  any  one  of  the  operations  fails,  then  the 
entire  transaction  fails.  Users  can  specify  the  degree  of  control 
and  notification  they  have  over  this  transaction.  For  example, 
making  a plane  reservation,  a rental  car  reservation,  and  a hotel 
reservation  for  a business  trip  would  result  in  high  overhead  and 
disjoint  control  if  each  action  were  taken  separately.  It  is  more 
efficient  to  do  all  of  these  in  a single  committed  operation. 
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since  if  a user  can  not  get  a plane  reservation,  the  car 
reservation  is  probably  irrelevant.  The  TP  application  allows  the 
user  to  find  out  whether  all  of  the  actions  can  be  completed 
successfully,  and  then,  if  they  can,  direct  that  they  be  carried 
out  as  a single  action.  TP  applies  among  distributed  systems,  and 
ensures:  1)  atomicity  (the  total  work  is  performed  or  nothing  is 
done)  , 2)  consistency,  3)  isolation  (while  the  work  is  being 
performed  inconsistent  data  is  not  available  to  other 
transactions) , and  4)  durability  (the  work  is  fault-tolerant) . 
This  last  point  is  especially  important  in  the  context  of  database 
management.  It  means  that  enough  information  will  be  retained  so 
that  in  the  event  of  a system  failure  the  information  on  the 
database  can  be  reconstructed.  Some  potential  uses  of  TP  are  in 
banking  transactions,  supply  and  accounting  systems,  and  network 
management . 

2. 2. 3. 1.5  Remote  Dat2d>ase  Access 

The  Remote  Database  Access  (RDA)  standard  [REF  7]  provides 
protocols  for  establishing  a remote  connection  between  a database 
client  and  a database  server.  The  RDA  standard  addresses 
distributed  database  processing  in  this  client/server  environment. 
RDA  specifies  a two-way  transfer  syntax  and,  when  combined  with  a 
database  specialization,  semantics  for  database  operations. 

The  RDA  standard  is  specified  in  two  parts.  Part  1 defines  the  RDA 
Generic  Model,  Service,  and  Protocol.  Part  2 defines  the  RDA 
Specification  for  Database  Language  SQL  [REF  8].  RDA  conformance 
can  only  be  expressed  in  conjunction  with  a specific  database 
language.  The  RDA  SQL  Specialization  allows  the  connection  of  RDA 
clients  with  RDA  servers  conforming  to  database  language  SQL.  Both 
the  client  and  the  server  must  conform  to  the  RDA  SQL 
Specialization  protocol;  however,  only  the  server  need  provide  an 
SQL  conformant  client  database  management  system.  The  client  can 
be  an  application  that  simply  sends  SQL  statements  to  the  server. 
SQL  is  thus  far  the  only  specialization  developed  to  complement  the 
RDA  Generic  Model,  Service,  and  Protocol. 

Users  can  read  database  entries  and  perform  updates  to  databases. 
Users  can  cancel  update  operations  without  penalty  and  receive 
instant  status  information  on  their  update  operation.  Users  can 
combine  database  entries  to  satisfy  specific  queries^  and  can 
execute  their  requests  immediately  or  save  them  for  execution  at  a 
later  time.  It  is  possible  to  have  a one-phase  commit  (which 
allows  updates  at  one  remote  site  per  operation) , or  two-phase 
commit  (which  allows  updates  at  multiple  remote  sites  in  the  same 
transaction) . RDA  can  be  used  to  support  access  to  SQL  systems, 
and  Call  Level  Interface  (CLI)  [REF  8]  functionality  could  be  used 
as  a standard  interface  to  various  databases. 

The  SQL  Access  Group  (now  part  of  X/Open  (see  sec.  2.4))  has 
divided  RDA  into  subsets  in  order  to  specify  basic 
interoperability.  Various  groups  are  prototyping  RDA  over  TCP/IP 
using  RFC1006  (see  sec.  2.3).  A Transport-Independent  RDA 
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specification  (a  separate  specification)  is  under  consideration  by 
various  groups  for  seamless  operation  over  a variety  of  transport 
stacks . 

Current  RDA  implementations  use  one-phase  commit;  implementations 
that  incorporate  two-phase  commit  depend  upon  the  popularity  of  TP 
and  may  not  be  available  in  the  near  term.  There  is  no  equivalent 
application  in  the  IPS.  Some  extensions  are  being  considered  to 
the  RDA  standard  that  would  support  a wider  range  of  SQL-type 
operations. 

2 .2. 3. 1.6  Directory  Service 

The  OSI  Directory  (joint  ISO-ITU-T  activity)  [REF  9]  is  a 
distributed  database,  capable  of  storing  information  about  people 
and  objects  in  various  servers  distributed  across  a network.  It  is 
these  servers,  acting  in  concert,  which  provide  the  potentially 
global  access  to  information  made  possible  by  Directory  technology. 

Distributing  information  in  this  manner  has  advantages  over  the 
conventional  method  of  centralizing  information  storage.  The 
information  is  kept  "close"  to  those  people  or  processes  which  are 
most  likely  to  make  most  frequent  use  of  it  and  are  most  likely  to 
be  responsible  for  keeping  it  up-to-date  - this  is  likely  to  reduce 
access  time  and  network  costs,  and  increase  the  likelihood  of  the 
accuracy  of  the  stored  information.  Since  the  information  is 
distributed  across  several  servers,  the  impact  of  a given  server 
becoming  inactive,  for  whatever  reason,  is  only  to  make  unavailable 
the  information  for  which  that  server  is  responsible,  rather  than 
bringing  down  the  entire  database,  as  would  be  the  case  if  a 
centralized  server  were  to  go  down.  The  Directory  has  the  capacity 
to  grow  indefinitely  in  size  and  storage  capacity  through  the 
simple  addition  of  new  nodes.  Such  growth  might  be  achievable  but 
would  be  less  practical  with  a centralized  system.  The  Directory 
offers  the  opportunity  to  unify  information  resources  across  the 
globe,  as  opposed  to  the  insularity  which  tends  to  occur  when 
organizations  rely  on  proprietary,  centralized  databases. 

The  physical  location  of  the  accessed  information  is  transparent  to 
the  user.  The  Directory  possesses  the  necessary  knowledge  to 
locate  requested  information,  regardless  of  where  the  information 
might  be  on  the  network.  All  information  received  will  usually 
appear  as  if  it  came  directly  from  the  local  server.  From  the 
user's  point  of  view,  the  Directory  behaves  exactly  as  if  the  user 
was  accessing  a centralized  server. 

The  Directory  user  accesses  the  Directory  via  a client  process 
known  as  a Directory  User  Agent,  or  DUA.  The  DUA  interfaces  with 
the  Directory  using  a standard  protocol  between  itself  and  one  of 
the  Directory  servers,  termed  Directory  System  Agents,  or  DSAs. 
Usually  the  DSA  contacted  would  be  the  one  closest,  in  terms  of 
connection  cost  or  organizational  affiliation,  to  the  Directory 
User  Agent. 
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The  DSAs  making  up  the  Directory  also  communicate  via  a standard 
protocol  which  embodies  a set  of  operations  which  may  be  performed 
by  the  Directory  (e.g.,  retrieving  information,  adding  information, 
etc.)«  Each  DSA  knows  how  to  contact  one  or  more  additional  DSAs 
(at  least  one) . This  is  the  mechanism  through  which  a Directory 
request  can  be  propagated  through  the  system:  if  a particular  DSA 
is  unable  to  satisfy  a request,  the  request  is  forwarded  to  another 
DSA  which  is  more  likely  to  have  the  necessary  information,  and  so 
on. 

The  entry  is  the  fundamental  unit  of  information  in  the  Directory. 
All  Directory  entries  are  made  up  of  a collection  of  attributes, 
each  of  which  describes  a particular  quality  or  aspect  of  the 
object  represented  by  the  entry.  For  example,  the  entry  for  "Tim 
Boland"  may  have  attributes  of  type  "telephone  number",  "street 
address",  and  "email  address".  Entries  are  grouped  into  classes  on 
the  basis  of  shared  properties. 

The  Directory  Schema  constitutes  the  framework  within  which 
Directory  information  is  stored.  It  consists  of  a set  of  rules  and 
definitions  which  define  the  naming  of  entries,  the  content  of 
attributes  and  entries,  the  structure  of  the  Directory  as  a whole, 
and  the  hierarchical  relationships  between  entries  (represented  in 
a structure  called  the  Directory  Information  Tree,  or  DIT) . Each 
entry  in  the  Directory  is  identified  by  at  least  one  unique  name, 
called  the  entry's  Distinguished  Name. 

The  Directory  offers  the  following  services  to  its  users:  (1)  read 
(retrieve  information  contained  in  an  entry) , (2)  list  (used 

primarily  to  browse  the  DIT) , (3)  compare  (compare  a user-supplied 
value  against  one  in  the  directory),  (4)  search  (look  for  entries 
which  match  specified  criteria) , (5)  add  entry  (add  a new  entry  to 
the  Directory,  (6)  remove  entry  (delete  an  entry  from  the 
Directory) , (7)  modify  the  contents  of  a directory  entry,  and  (8) 
modify  Distinguished  Name  (change  the  Distinguished  Name  of  an 
entry)  . These  services  may  be  presented  in  a variety  of  ways, 
depending  on  the  directory  user  agent  product  in  use.  Attached  to 
a DUA  may  be  a user  interface,  an  X.400  application,  or  a database 
application,  among  other  choices. 

Additional  services  provided  by  the  Directory  are  security  and 
replication.  The  security  services  include:  (1)  authentication  of 
Directory  users  to  establish  their  identity,  and  (2)  access  control 
procedures  to  prevent  unauthorized  access  to  Directory  information. 
Replication  is  the  means  by  which  information  held  by  a DSA  may  be 
copied  to  one  or  more  other  DSAs  in  order  to  increase  efficiency 
and  decrease  access  time. 

2 .2. 3. 1.7  Additional  OSI  Applications 

The  Information  Retrieval  (IR)  application  [REF  10]  supports  the 
open  interconnection  of  information  clients  with  information 
servers  by  specifying  an  OSI  application  layer  protocol  for 
intersystem  search  and  retrieval  of  information.  The  IR 
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application  provides  retrieval  (but  not  update)  of  information  and 
the  IR  protocol  specifies  basic  information  retrieval  operations, 
a common  syntax  for  queries  and  the  means  to  express  their 
semantics,  and  the  means  to  allow  the  partner  systems  to  share  an 
understanding  of  the  information  retrieved. 

The  Manufacturing  Messaging  Specification  (MMS)  standard  [REF  11] 
provides  for  client/server  message  based  communications  between 
programmable  devices  in  a computer  controlled  environment.  MMS 
defines  messages  useful  for  information  interchange.  It  does  not 
define  a complete  set  of  services  for  remote  device  programming. 

2. 2. 3. 2 NetworX  Management 

Network  management  allows  users  to  configure  network  resources, 
detect  and  correct  faults,  account  for  network  use,  monitor  and 
adjust  performance,  and  manage  security  mechanisms.  A user  can 
also  determine  what  network  resources  need  to  be  managed.  Network 
management  is  provided  by  a family  of  standards  [REF  12]  (formally 
known  as  OS I Systems  Management)  covering  the  areas  of  management 
communications,  management  information,  and  systems  management 
functions  and  services.  The  management  communications  protocol  is 
the  Common  Management  Information  Protocol  (CMIP) . To  provide 
interoperability  among  network  management  systems,  each  system  must 
have  a common  "view"  of  management  information.  System  resources 
to  be  managed  are  represented  by  managed  objects  using  an  object 
oriented  model.  OS I Systems  Management  may  be  applied  to  system 
resources  (e.g. , buffers,  disks),  not  just  to  networks. 

An  example  of  OSI  network  management  is  event  notification  of 
excessive  CPU  utilization  in  two  interconnected  systems  to  a remote 
manager.  The  manager  may  then  take  action  to  offload  some  of  the 
work . 


For  OSI  network  management,  work  is  progressing  on  additional 
managed  object  definitions  and  management  profiles.  Standards  work 
is  also  continuing  in  the  areas  of  performance,  security, 
accounting,  configuration,  and  fault  management. 

The  OSI  network  management  protocols  have  been  relatively  slow  to 
be  deployed,  with  only  a few  companies  having  products  available. 
Since  the  release  of  OmniPoint  (Open  Management  Interoperability 
Points:  TM  - Network  Management  Forum) , more  vendors  have 
implemented  OSI  network  management,  particularly  for  larger,  more 
complex  (enterprise)  networks  in  the  worldwide  telephony  industry. 

A user  should  employ  IPS  network  management  (SNMPvl,  see  sec. 
2. 1.3. 3)  when  the  devices  to  be  managed  are  simple  and  fewer  in 
number  (for  example,  those  that  appear  on  a LAN) , because  many 
relatively  inexpensive  products  are  available.  For  more  complex 
devices  (or  for  a larger  number  of  different  devices) , such  as 
those  that  appear  on  an  enterprise  network,  OSI  network  management 
may  be  a better  approach,  if  vendors  support  OSI  management  in 
their  manageable  products.  SNMPvl  is  a "lightweight"  alternative 
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to  CMIP. 


The  IPS  and  OS  I network  management  protocols  can  and  have  been 
deployed  over  alternative  transports.  For  example,  there  are 
several  mixed  protocol  stack  approaches  defined,  including  CMIP  for 
the  Internet,  CMIP  over  logical  link  control  (LLC) , and  SNMP  over 
OSI.  In  addition,  there  are  a set  of  specifications  known  as  ISO 
Internet  Management  Coexistence  (IIMC)  that  defines  methods  for  the 
management  of  SNMP  resources  using  OSI  managers  and  vice  versa. 
There  has  been  limited  deployment  of  implementations  based  on  the 
IIMC  specifications. 

2 . 2 . 3 . 3 Security 

The  security  services  provided  in  the  OSI  model  are  authentication, 
access  control,  integrity,  confidentiality,  and  non-repudiation. 
Data  confidentiality  services  protect  against  unauthorized 
disclosure.  Protection  of  medical  records  to  insure  a patient's 
privacy  is  an  example  of  the  need  for  confidentiality.  Data 
integrity  services  protect  against  unauthorized  modification, 
insertion  and  deletion.  Electronic  funds  transfer  between  banks 
requires  protection  against  modification  of  the  information. 
Authentication  services  verify  the  identity  of  communicating  peer 
entities  and  the  source  of  data.  Owners  of  bank  accounts  require 
assurance  that  money  will  be  withdrawn  only  by  them.  Access 
control  services  allow  only  authorized  communications  and  access  to 
system  resources.  Only  financial  officers  are  authorized  access  to 
a company's  financial  plans.  Non-repudiation,  with  proof  of 
origin,  provides  to  the  recipient  proof  of  the  origin  of  data  and 
protects  against  any  attempt  by  the  originator  to  falsely  deny 
sending  the  data.  Non-repudiation,  with  proof  of  delivery, 
provides  to  the  sender  proof  of  the  delivery  of  data.  The  non- 
repudiation service  can  be  used  to  prove  to  a judge  that  a person 
received  or  sent  a message  (e.g.,  a purchase  order). 

The  OSI  architecture  defines  security  protocols  at  the  Transport 
Layer,  Network  Layer,  and  the  Application  Layer.  NLSP  (Network 
Layer  Security  Protocol)  provides  security  services  at  the  Network 
Layer,  and  TLSP  (Transport  Layer  Security  Protocol)  provides 
security  services  at  the  Transport  Layer.  Different  application 
layer  protocols  may  integrate  security  services.  For  example,  for 
Message  Handling  Systems,  these  services  are  accomplished  by  having 
a special  module  between  the  User  Agent  and  the  Message  Transfer 
Agent  which  uses  public  and  private  keys  to  provide  authentication 
and  integrity  (on  a message-by-message  basis) . 

As  an  illustration,  authentication/ integrity . are  provided  in  a 
message  as  follows;  (1)  the  originator  computes  a checksum  of  the 
text,  then  the  originator  encrypts  the  checksum  using  the 
originator's  private  key,  (2)  when  the  recipient  receives  the  text, 
it  decrypts  the  checksum  using  the  originator's  public  key,  and 
then,  independently,  computes  the  checksum  and  compares  the  two 
values,  and  (3)  if  the  values  are  equal,  the  message  has  not  been 
changed  and  the  message  has  been  sent  by  the  originator.  If  a 
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confidentiality  service  is  required,  the  outgoing  message  is 
encrypted  using  a specified  key.  Each  new  message  can  be  encrypted 
with  a different  key,  and  the  key  that  is  used  is  encrypted  using 
each  recipient's  public  key.  When  the  recipient  receives  the 
message,  the  recipient's  private  key  is  used  to  decrypt  the  key 
that  was  used  to  encrypt  the  message  and  then  that  key  is  used  to 
perform  the  message  decryption. 

At  the  Network  Layer,  the  security  services  are  provided  between 
adjacent  intermediate  systems.  At  the  Transport  Layer,  the 
security  services  are  provided  between  the  communicating  end 
systems.  The  security  services  provided  at  the  Transport  and 
Network  Layers  apply  to  all  applications;  the  security  services 
provided  at  the  Application  Layer  can  be  on  a per-application 
basis.  Thus  far,  implementation  of  OSI  security  services  has  been 
at  the  Application  Layer.  There  has  been,  thus  far,  little  or  no 
user  interest  in  having  these  services  provided  at  the  Network  or 
Transport  Layers. 

2 .2. 3. 4 Application  Program  Interfaces 

An  application  programming  interface  (API)  is  a conceptual  boundary 
between  an  application  process  or  program  and  a service  provider. 
Through  this  boundary,  information  is  transferred  in  a structured 
manner.  APIs  are  programmable  interfaces  which  link  application 
software  on  a variety  of  application  platforms  to  a collection  of 
hardware  and  software  components. 

The  advantages  of  API  use  are  modularity  and  portability. 
Modularized  code  is  written  in  localized  routines  or  macros  so  that 
service  provider  software  may  be  separated  from  other  applications 
code.  This  means  that  changes  in  the  former  may  occur  without 
affecting  the  latter,  and  vice  versa.  Portable  code  can  be  moved, 
or  ported,  to  a different  environment,  and  it  should  operate  in  the 
same  fashion  as  before. 

Standardized  OSI  APIs  are  being  developed,  at  the  Transport, 
Session,  Presentation,  and  Application  Layers.  These  APIs  describe 
methods  for  accessing  the  services  of  these  layers  in  a uniform 
way.  The  Institute  of  Electrical  and  Electronic  Engineers  (IEEE) 
has  standardized  APIs  for  Message  Handling  Systems,  Directory 
Services,  FTAM,  Generic  Application  Layer,  and  Presentation  Layer. 

Other  de  facto  APIs  are  being  developed,  such  as  the  Microsoft 
Messaging  API  (MAPI) . MAPI  is  a high-level  API  involving  common 
messaging  functions  which  provides  ease  of  use  and  simplicity. 
Support  of  MAPI  by  OSI  messaging  is  anticipated.  MAPI  is  largely 
independent  of  the  underlying  message  system  used.  Simple  MAPI 
(the  common  messaging  functions  themselves)  is  available  now,  and 
extended  MAPI  (with  extra  features  such  as  file  folder  support) 
should  be  available  in  the  near  future.  Simple  MAPI  may  be 
considered  a subset  of  extended  MAPI  for  the  purposes  of 
interoperability. 
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2.3  Coexistence  auid  Convergence 

Coexistence  and  interoperability  of  different  protocol  suites  (for 
example,  OS  I and  IPS)  has  emerged  as  a strong  requirement. 
Although  protocol  convergence  is  an  ideal  target,  this  may  still  be 
a long-term  goal,  in  particular  for  application  protocols,  where 
gateway  operation  may  be  the  only  way  of  interoperability  for  a 
long  time.  However,  for  some  applications,  common  databases  are 
being  considered,  e.g.,  for  systems  management. 

A hybrid  stack  is  a selection  of  protocols  in  each  functional  layer 
such  that  the  protocols  selected  come  from  different  protocol 
suites.  The  hybrid  stack  that  is  most  likely  to  be  deployed  is 
layers  5 through  7 from  the  OSI  protocol  suite,  operating  with 
layers  1 through  4 from  the  IPS.  Hybrid  stacks  are  used  to  take 
advantage  of  existing  or  enhanced  capabilities,  and  allow  a user  to 
custom-design  an  environment.  The  powerful  capabilities  of  OSI 
applications  can  be  used  with  the  existing  IPS  infrastructure  to 
capture  the  advantages  of  both.  A hybrid  stack  can  interoperate 
only  with  another  identical  hybrid  stack. 

The  most  popular  solution  for  allowing  OSI  applications  to  run  over 
TCP/IP  is  specified  in  RFC1006  [REF  13].  RFC1006  allows  a TCP 
interface  to  appear  as  an  OSI  Transport  service  interface.  RFC1006 
allows  OSI  application  protocols  to  be  operated  over  an  IP  network, 
by  specifying  the  provision  of  the  OSI  Transport  Service  over  the 
Internet  TCP.  RFC1006  does  not  provide  a way  for  OSI  applications 
on  an  OSI  network  to  interwork  with  OSI  applications  on  Internet 
networks . 

XTI  (X/Open  Transport  Interface)  has  been  developed  by  the  X/Open 
consortium  to  provide  applications  independence  from  any  particular 
transport  provider.  That  does  not  mean  that  it  automatically  makes 
the  application  entirely  independent  of  the  class  of  service 
provided,  i.e.,  connectionless  and  connection-oriented  with  or 
without  orderly  release.  However,  a truly  transport- independent 
application  can  be  written  using  XTI  if  no  assumptions  are  being 
made  by  the  application  about  the  nature  of  the  underlying 
transport  service,  i.e.,  as  long  as  it  does  not  expect  that  all 
concepts  used  in  one  protocol  exist  or  have  the  same  semantics  in 
other  ones.  Existing  applications  have  to  be  modified  to  use  XTI. 
Industry-consensus  specifications  of  how  to  use  XTI  over  OSI, 
TCP/IP,  RFC1006,  and  Systems  Network  Architecture  (SNA)  full  duplex 
have  been  developed  and  published. 

The  X/Open  Multi-Protocol  Transport  Networking  (XMPTN) 
specification  is  designed  for  interworking  transport  users 
(applications)  that  have  the  same  requirements  for  transport 
services,  or,  in  other  words,  "match"  each  other.  This  means  that 
the  investment  in  current  applications  is  preserved. 

A dual  protocol  host  (or  dual  stack)  has  the  complete  OSI  and 
Internet  protocol  suites  available  as  part  of  its  networking 
capabilities.  A user  of  such  a host  would  have  the  option  of 
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invoking  the  IPS  application  protocols  or  the  analogous  OSI 
application  protocols.  A dual  protocol  host  can  be  used  directly 
by  users  with  accounts  on  it  to  communicate  to  any  OSI  or  IPS 
destination.  It  can  also  be  used  as  a staging  point  for  manual 
interoperation  between  a host  that  has  only  IPS  protocols  and  a 
host  that  has  only  OSI  protocols. 

2 . 4 Consortia 

As  an  alternative  to  the  OSI  and  IPS  approaches,  vendors  and  users 
have  consolidated  operations  in  consortia.  A consortium  is  an 
organization  whose  aim  is  to  develop  or  implement  open  systems 
solutions.  There  are  usually  extensive  requirements  for  full 
membership,  and  members  usually  pay  membership  fees.  There  may  be 
differing  levels  of  membership,  and  consortia  are  usually  non- 
accredited.  Specifications  are  produced  which  reflect  member 
consensus.  The  processes  for  formation,  document  approval  and 
operation  are  specific  to  each  consortium.  There  are  two  types  of 
consortia:  those  that  create  specifications  (like  X/Open) , and 
those  which  develop  working  code  (like  the  Open  Software  Foundation 
(OSF) ) . Consortia  may  anticipate  future  standards  development  and 
implementation,  or  define  alternative  solutions.  Their  work  may  be 
submitted  to  accredited  national  standards  bodies.  Consortia  are 
usually  vendor  dominated.  Members  of  consortia  may  be  free  to 
develop  innovative  solutions  free  of  other  constraints. 

An  example  of  a consortium-produced  open  systems  solution  is  the 
Open  Software  Foundation's  Distributed  Computing  Environment  (DCE)  . 
DCE  is  a set  of  services  and  tools  that  support  the  creation,  use, 
and  maintenance  of  distributed  applications  in  a heterogeneous 
computing  environment.  The  DCE  components  fall  into  two 
categories:  tools  for  developing  distributed  applications,  and 
services  for  running  distributed  applications.  The  tools,  such  as 
DCE  Remote  Procedure  Call  (RPC)  and  DCE  Threads,  assist  in  the 
development  of  an  application.  The  services,  such  as  the  DCE 
directory  service,  security  service,  and  distributed  time  service, 
provide  the  support  required  in  a distributed  system  that  is 
analogous  to  the  support  that  an  operating  system  provides  in  a 
centralized  system.  DCE's  set  of  services  is  integrated  and 
comprehensive.  DCE  claims  to  provide  interoperability,  portability 
and  data  sharing  across  heterogeneous  platforms.  The  DCE  is 
independent  of  the  underlying  networking  infrastructure;  DCE 
applications  can  use  the  Network  and  Transport  Layers  of  either  the 
OSI  or  Internet  protocol  suite. 

As  another  example  of  a consortium  produced  open  systems 
alternative,  the  Common  Object  Request  Broker  Architecture  (CORBA) 
was  developed  by  the  Object  Management  Group  (OMG) . CORBA  defines 
an  interface  to  an  Object  Request  Broker  (ORB),  which  provides  the 
mechanisms  that  allow  objects  to  make  rec[uests  on  other  objects  and 
receive  responses  to  those  requests.  By  building  objects  atop  an 
ORB  and  by  relying  on  the  ORB  for  communications  between  those 
objects,  an  application  developer  does  not  have  to  worry  about 
where  other  objects  are  and  how  requests  made  on  those  objects 
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actually  get  to  them.  An  ORB  has  software  to  insulate  end  users 
from  this  knowledge.  CORBA  also  defines  a protocol  allowing 
interoperability  among  different  vendor's  object  request  brokers. 
CORBA  is  an  approach  to  distributed-object  computing.  Vendors 
offer  products  that  support  the  CORBA  technology,  although  there 
are  interoperability  problems  caused  by  incomplete  specifications. 
CORBA  applications  could,  in  theory,  use  either  IPS  or  OSI 
communications  protocols. 
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3 . 0.  Strategy 
3 . 1 General 

The  two  principal  non-proprietary  data  communications  protocols  are 
the  Open  Systems  Interconnection  (OSI)  protocol  and  the  Internet 
Protocol  Suite  (IPS) . Any  strategy  for  using  non-proprietary  data 
communications  technology  must  consider  to  what  exte'nt  each  of 
these  protocol  suites  satisfies  the  user's  requirements.  Many 
users  will  find . that  neither  protocol  suite,  by  itself,  is 
sufficient  and  that  both  protocol  suites  or  hybrids  of  both 
protocol  suites  are  needed.  In  addition,  certain  consortia 
developed  applications  may  provide  services  that  are  critical  to  a 
user's  mission.  'The  international  standards  process  that  produced 
the  OSI  protocols  has  not  lead  to  the  widespread  availability  of 
computer  networking  products  at  prices  that  most  users  found 
attractive.  Products  result  from  an  interaction  between  vendors 
and  users  in  which  vendors  try  to  understand,  even  anticipate,  user 
needs  and  then  develop  products  in  response  to  those  needs.  The 
vendors'  goal  is  always  to  increase  their  share  of  the  market  in 
which  they  compete  and  to  maximize  profits.  Users  vote  on  the 
vendors'  strategy  with  their  pocketbooks.  If  the  user  reaction  is 
favorable,  vendors  will  produce  more  of  the  same  product  which  they 
can  now  make  and  market  at  a lower  price,  further  stimulating 
demand.  If  the  user  reaction  is  unfavorable,  vendors  will  rethink 
their  marketing  strategy  and  make  the  necessary  adjustments. 

There  was  interaction  between  vendors  and  users  in  the  development 
of  the  OSI  standards.  The  international  organizations  that 
produced  the  OSI  standards  and  the  workshops  that  produced  the 
functional  profiles  based  on  the  standards  welcomed  users. 
Although  the  process  was  dominated  by  vendors,  a significant  number 
of  users,  mostly  from  the  technical  staff  of  large  corporations, 
regularly  participated.  These  same  organizations,  however,  did  not 
rush  forward  to  purchase  products  after  they  had  been  implemented. 
In  fact,  one  result  of  user  participation  in  the  standards  process 
was  that  the  users  themselves  had  varying  requirements  and 
represented  additional  interests,  each  of  which  had  to  be 
accommodated  in  developing  the  standards.  This  increased  the 
complexity  of  the  standards,  increased  the  cost  of  implementations 
based  on  the  standards  and,  consequently,  decreased  user  interest 
in  purchasing  the  resulting  products. 

For  any  commodity,  the  final  user's  decision  to  buy  or  not  to  buy 
is  always  based  on  the  services  provided,  the  cost,  and  the 
available  alternatives.  The  technical  staff  of  the  vendor  and  user 
organizations  that  developed  the  OSI  standards  did  not  control  the 
purse  strings  of  their  organizations  and  dialogue  about  the 
relationship  between  services  and  cost  did  not  occur.  In  fact,  the 
complexity  of  some  applications,  resulting  from  the  tendency  of  the 
standards  organizations  to  please  everybody,  was  seen  as  a 
drawback,  not  as  an  enhancement,  and  not  desirable  at  any  price. 
The  end  result  is  that  the  OSI  protocols  are  likely  to  be  evaluated 
by  users  on  a case-by-case  basis.  Some  of  the  OSI  protocols  (e.g.. 
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the  Virtual  Terminal  Protocol)  were  dead  on  arrival  or,  to  be  more 
precise,  they  never  arrived.  They  were  implemented  by  only  a few 
vendors  and  the  specifications  are  still  gathering  dust  in  the 
files  of  the  large  vendors.  Use  of  other  OSI  protocols  (e.g.,  the 
File  Transfer  Access  and  Management  (FTAM)  Protocol)  will  likely  be 
confined  to  certain  niches  of  the  market.  Still  other  OSI 
protocols  (e.g.,  X.400,  X.500  (Directory  Service))  should  enjoy 

increasingly  greater  user  acceptance  because  they  provide  services 
that  users  value  and  the  ability  to  procure  a hybrid  stack 
implementation  allows  users  to  procure  these  services  without 
committing  to  acquisition  and  use  of  the  full  seven  layers  of  the 
OSI  protocol  suite. 

It  was  previously  stated  that  the  available  alternatives  are  a 
major  factor  in  any  procurement  decision.  Because  of  the 

complexity,  delays  and  costs  associated  with  the  OSI  protocols,  the 
Internet  Protocol  Suite,  a protocol  suite  not  originally  designed 
with  the  business  user  in  mind,  became  an  increasingly  viable 
alternative  for  procurers  of  computer  networking  services. 
Although  use  of  the  Internet  Protocol  Suite  was  fueled  by  the 
explosive  growth  of  the  Internet,  there  was  no  constraining  linkage 
and  use  of  the  IPS  spread  rapidly  to  non-Internet  networks. 
Although  the  IPS  was  originally  designed  for  research  and 
development  users  in  the  Department  of  Defense,  service  upgrades 
are  being  made  to  enable  use  in  a wider  business  environment.  The 
frequent  service  upgrades  to  both  the  IPS  and  OSI  protocol  suites 
complicates  the  procurement  decision  process  and  requires  a 
continuing  assessment  of  the  available  technology. 

This  section  will  examine  some  of  the  technical  and  marketplace 
factors  that  should  influence  a user's  procurement  decision.  Some 
of  the  guidance  will  be  general  in  nature;  other  guidance  will  be 
specific  to  the  services  being  procured.  When  more  than  one  viable 
alternative  exists,  users  must  thoroughly  understand  their  own 
requirements  as  well  as  the  services  provided  by  the  alternative 
protocols.  Only  then  will  they  be  able  to  perform  an  effective 
matching  of  requirements  and  available  technology  that  is  essential 
when  making  good  procurement  decisions.  All  of  the  following 
principles  are  not  specific  to  the  procurement  of  computer 
networking  products  and  services.  Even  though  some  would  consider 
these  principles  an  application  of  common  sense,  they  are  discussed 
because  they  are  frequently  violated  in  the  procurement  process. 

1.  Determine  the  community  of  users  with  whom  you  currently 
interoperate  and  those  with  whom  you  intend  to  interoperate  in 
the  future.  Develop  interoperability  agreements  with  that 
community  of  users. 

The  original  vision  of  the  international  standards  community  was 
that  their  efforts  would  result  in  one  set  of  internationally 
recognized  data  communication  protocols  which  would  be  implemented 
worldwide.  The  protocols  which  they  standardized  would  allow,  for 
example,  a Federal  agency  user  in  the  United  States  to  send  mail  to 
a French  corporation  and  to  receive  mail  from  a university  in  Japan 
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with  the  assumption  that  all  users  would  have  the  same  networking 
infrastructure  and  the  same  application  layer  services.  There 
would  be  a globally  distributed  Directory  Service  supporting  the 
transfer  of  electronic  mail.  There  would  also  be  the  capability  of 
retrieving  files,  accessing  remote  data  bases,  and  performing 
transaction  processing  using  the  same  internationally  recognized 
set  of  protocols.  A standardized  set  of  applications  would  satisfy 
most  of  the  requirements  of  business  users;  they  would  only  need  to 
develop  the  special  purpose  applications  of  interest  to  their  own 
community  and  even  these  would  interoperate  over  the  standardized 
networking  infrastructure.  That  vision,  however,  has  been 
overtaken  by  reality.  The  data  communications  world  will  consist 
of  multiple  non-proprietary  and  proprietary  alternatives  for  data 
transfer.  Any  user  choice  can  lock  out  future  communication  with 
other  users.  It  is  critical  that  representatives  of  all 
organizations  or  groups  that  need  to  interoperate  participate  in 
selecting  the  protocols  that  will  permit  interoperation.  This  may 
require  inter-agency  groups  to  be  formed  or  even  groups  that 
include  non-government  organizations  that  want  to  have  on-line 
access  to  government  data.  By  "circling  the  wagons"  around  the 
community  of  users  with  common  interests,  and  making  decisions  that 
are  agreed  by  and  apply  to  that  community,  procurement  authorities 
will  insure  that  they  will  not  be  adversely  impacted  by 
developments  over  which  they  have  no  control. 

2.  Determine  the  computer-networking  services  which  are  essential 
to  the  conduct  of  business  in  your  organization.  Determine 
those  services  which,  though  desirable,  are  not  essential  to 
the  business  enterprise. 

The  services  that  are  procured  determine  the  cost.  Separating  the 
essential  from  the  merely  desirable  allows  the  procurement 
authorities  some  flexibility  when  negotiating  with  the  vendors.  In 
making  this  distinction,  it  should  not  be  assumed  that  services 
that  are  required  by  some  personnel  need  to  be  provided  to  all 
personnel . 

3.  All  policy  decisions  should  take  into  account  the  Information 
Technology  budget.  Standards  groups  within  an  organization 
should  not  set  policy  requiring  the  procurement  of  computer 
networking  services  if  there  is  no  money  to  pay  for  them. 

This  rule  is  often  violated  by  Federal  agencies.  The  standards 
group  has  limited  interaction  with  the  budget  group  and  the  budget 
group  frequently  cannot  anticipate  the  availability  of  funds  beyond 
the  current  fiscal  year.  Even  when  there  are  budgetary 
uncertainties,  the  standards  group  should  still  issue  computer 
networking  policy  which  sets  the  direction  for  the  organization. 
This  policy  should  have,  in  advance,  the  endorsement  and  support  of 
everyone  affected  by  the  policy,  particularly  top  management. 

4 . Be  knowledgecd:>le  about  the  networking  services  provided  by 
current  products  and  about  vendor  plans  for  augmenting  those 
services  in  the  future. 
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The  removal  of  the  requirement  to  acquire  OSI  products  allows 
Federal  agencies  more  options  when  procuring  computer  networking 
products  but  it  also  requires  them  to  be  more  informed  about  the 
functional  capabilities,  performance,  cost  and  availability  of  each 
option.  Users  need  to  regularly  consult  the  trade  press  and  their 
vendors  to  anticipate  advances  in  computer  networking  technology  so 
that  they  do  not  procure  functionality  that  will  soon  be  obsolete. 
It  is  important  that  the  interaction  between  users  and  vendors  be 
a dialogue;  the  issuance  of  user  requirement  documents  or  profiles 
will  do  nothing  to  influence  vendor  actions  unless  these  documents 
are  backed  up  with  a significant  amount  of  procurement  funds. 

5.  Develop  a realistic  workable  transition  strategy  that  is 
appropriate  for  all  users  affected  by  the  procurement. 

User  resistance  to  the  introduction  to  new  technology  can  be 
expected  unless  the  users  understand  how  the  new  technology  will 
improve  efficiency  and  make  their  job  easier.  If  the  transition 
involves  some  temporary  hardships,  users  must  be  able  to  see  how 
these  inconveniences  are  a necessary  part  of  an  overall  rational 
transition  strategy.  The  transition  strategy  that  is  adopted 
should  be  evaluated  at  regular  intervals  to  determine  whether  the 
original  expectations  are  being  met  and,  if  not,  to  make  the 
necessary  adjustments. 

3.2  Testing 

Users  should  consider  carefully  the  type  and  extent  of  testing  that 
will  be  required  and  avoid  unnecessary  duplication.  There  are  four 
categories  of  testing  that  should  be  considered  when  procuring 
computer  networking  products:  conformance  testing, 
interoperability  testing,  performance  testing  and  functional 
testing.  The  purpose  of  each  type  of  testing  is  discussed  in 
Appendix  A.  Appendix  A also  discusses  current  testing  procedures 
and  specifies  the  organizations  that  are  responsible  for  evaluating 
and  registering  test  results. 

Since  there  is  a cost  associated  with  all  new  testing  that  is 
mandated  in  connection  with  a procurement,  both  users  and  vendors 
should  have  an  interest  in  keeping  new  testing  to  a minimum  and 
making  use  of  any  information  about  the  technology  to  be  procured 
that  is  publicly  available,  even  if  it  is  not  formally  recorded. 

Some  of  the  factors  that  should  be  considered  in  making  the  testing 
decision  are: 

1.  Level  of  maturity  of  the  technology  being  procured. 

The  fact  that  the  computer  networking  protocols  in  the  product 
to  be  procured  have  been  operating  successfully  in  a real- 
world  environment  over  an  extended  period  of  time  should  give 
most  users  an  increased  level  of  confidence  in  that  product 
even  if  the  protocols  have  not  undergone  formal  conformance  or 
interoperability  testing.  Testing  which  focuses  on  areas  of 
specific  concern  to  the  user  may  be  all  that  is  warranted. 
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Magnitude  of  the  Procurement 

In  a small  procurement,  additional  mandated  testing  can  add 
significant  overhead  to  the  procurement  cost.  In  a large 
procurement,  the  testing  may  add  only  a small  increment  to  the 
procurement  costs. 

3.  Number  of  Current  Validated  Products 

If  multiple  products  satisfying  a user's  requirements  already 
exist  on  a register,  the  user  should  procure  one  of  those 
products  instead  of  requiring  additional  testing  by  a vendor 
whose  products  have  not  yet  been  formally  certified. 

4.  Avail2U3ility  of  Tests  and  Test  Systems 

Users  should  not  mandate  testing  if  there  are  no  test  systems 
or  only  test  systems  of  dubious  quality  available  to  perform 
the  testing.  Users  should  have  a thorough  understanding  of 
the  tests  and  systems  to  be  used  before  they  require  testing 
in  a procurement. 

5.  Criticality  of  the  Services  Being  Acquired 

Users  should  develop  a worst-care  scenario  for  the  impact  on 
their  organization  if  an  error  or  errors  should  occur  in  the 
computer  networking  protocols  that  are  being  procured.  If  the 
result  is  only  a minor  disruption  in  the  activities  of  the 
organization,  users  may  determine  that  an  increased  confidence 
level  is  not  worth  the  cost  of  additional  testing.  If, 
however,  a single  error  has  the  potential  of  causing  a severe 
security  breach  or  a large  financial  loss,  then  the  additional 
cost  of  testing  may  be  a very  wise  investment. 

3.3  Security 

Each  organization  should  determine  its.  requirement  for  the 
following  security  services: 

(1)  Data  Integrity  services  protect  communicated  data  from 
unauthorized  modification,  insertion,  or  deletion. 

(2)  Authentication  services  identify  and  authenticate  the 
data  originator  to  all  recipients.  Authentication 
services  are  necessary  for  implementing  access  control. 

(3)  Access  control  services  allow  only  authorized 
communications  and  access  to  system  resources. 

(4)  Non-repudiation  protects  against  any  attempt  by  the 
originator  of  the  communicated  data  to  later  falsely  deny 
sending  the  data. 

(5)  Data  confidentiality  services  protect  against  unauthorized 
disclosure. 

Some  organizations  may  find  that  their  authentication  requirements 
can  be  met  by  unprotected  or  protected  passwords.  Other 
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organizations  will  find  that  they  have  a requirement  for  strong 
authentication  services.  Strong  authentication  services  are  based 
on  the  use  of  digital  signatures  which  rely  on  the  use  of  public 
key  cryptographic  techniques.  These  techniques  also  provide 
assurances  of  data  integrity  and  protect  against  originator 
repudiation  as  a by-product  to  the  strong  authentication  service. 
The  National  Institute  of  Standards  and  Technology  issued  Federal 
Information  Processing  Standard  (FIPS)  186,  Digital  Signature 
Standard  [REF  14],  which  became  effective  on  December  1,  1994  as 
the  government  standard  for  use  by  all  Federal  agencies  which 
require  a public  key  cryptographic  signature  system  for 
unclassified  sensitive  information. 

Public  key  cryptography  makes  use  of  two  paired  keys:  a public  key 
and  a private  key.  The  public  key  can  be  known  by  anyone.  The 
private  key  is  secret  and  its  use  is  controlled  by  its  owner. 
Encryption  performed  using  a private  key  can  be  decrypted  using  the 
corresponding  public  key;  encryptions  performed  using  a public  key 
can  be  decrypted  using  the  corresponding  private  key.  In  order  for 
public  key  cryptography  to  work  effectively,  there  must  be  a 
Certification  Authority  which  is  responsible  for  the  public/private 
key  pairs  and  for  securely  transferring  the  private  key  to  the 
associated  user.  Discussions  are  underway  within  the  Federal 
government  relating  to  how  this  service  will  be  provided  and  who 
should  provide  it.  It  is  expected  that  it  will  be  several  years 
before  a Certification  Authority  service  will  be  implemented  and 
available  to  all  Federal  agency  users. 

The  Digital  Signature  Standard  does  not  provide  a confidentiality 
service.  If  confidentiality  is  required,  the  data  originator  could 
first  encrypt  the  message  using  the  Data  Encryption  Standard  (DES) 
before  signing  it,  using  the  algorithm  specified  in  the  Digital 
Signature  Standard. 

There  is  another  technique,  however,  of  providing  a confidentiality 
service  in  such  a way  that  it  does  not  jeopardize  effective  law 
enforcement,  public  safety,  and  national  security.  Furthermore, 
the  infrastructure  required  to  implement  this  technique  is 
currently  operational.  The  technique  is  based  on  a special  tamper 
resistant  hardware  encryption  device  (Capstone  Chip)  which 
implements  a strong  encryption  algorithm  (SKIPJACK)  and  a Key 
Escrow  System  which  gives  the  government  access  to  a device  unique 
key  that  unlocks  all  communications  encrypted  by  the  chip  pursuant 
to  a lawful  court  order. 

This  method  of  providing  confidentiality  services  has  been  endorsed 
by  the  Department  of  Defense  (DOD)  and  will  be  implemented  in  the 
recently  awarded  Defense  Messaging  System.  The  SKIPJACK  algorithm 
will  be  implemented  on  a FORTEZZA  Personal  Computer  card.  Several 
hundred  thousand  DOD  users  will  receive  FORTEZZA  cards  to  encrypt 
and  authenticate  messages  in  the  Defense  Messaging  System.  The 
FORTEZZA  card,  which  is  inserted  into  a PC  card  reader,  contains 
specific  cryptographic  algorithms,  unique  encryption  and  decryption 
keys  and  other  information  that  can  be  used  to  encrypt  messages 
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sent  to  other  FORTEZZA  card  users  and  decrypt  and  authenticate 
messages  received  from  other  FORTEZZA  card  users.  This  system 
requires  that  users  procure  a FORTEZZA  card  and  that  their  PCs  be 
equipped  with  a card  reader.  The  cost  of  the  FORTEZZA  cards  is 
declining  (currently  about  $70)  but  the  requirement  for  a PC  card 
reader  may  be  a significant  barrier  to  widespread  deployment 
outside  of  DOD.  Another  alternative  that  is  being  investigated  and 
tested  in  a pilot  program  is  to  put  the  Data  Encryption  Standard 
(DES)  [REF  15]  and  DSS  algorithms  and  required  key  material  on  a 
3.5  inch  floppy  drive.  Since  no  modification  to  existing  PCs  would 
be  required,  this  method  should  be  particularly  attractive  to 
agencies  like  the  IRS  who  have  a need  to  securely  send  messages  to 
and  receive  messages  from  private  citizens. 

3.4  Network  Management 

There  are  three  main  protocols  for  consideration:  (1)  CHIP  (see 
sec.  2. 2. 3. 2),  (2)  SNMPvl  (see  sec.  2. 1.3. 3),  and  (3)  DCE 
management  (see  sec.  2.4).  It  is  likely  that  SNMPvl  will  be  the 
network  management  protocol  implemented  on  most  LANs?  there  are 
many  SNMPvl  products  available,  but  SNMPvl  is  lacking  in  security 
functionality.  CMIP  may  be  more  appropriate  for  larger,  more 
complex  enterprise  environments,  but  there  are  not  many  products 
available.  Similarly,  there  are  also  not  many  DCE  management 
products  available. 

3.5  Electronic  Mail  and  Directory  Services 

In  July  1993,  the  Office  of  Management  and  Budget  .(0MB)  chartered 
an  Electronic  Mail  Task  Force  (EMTF)  to  examine  the  state  of 
electronic  messaging  among  Federal  agencies  and  to  make 
recommendations  on  what  should  be  done  to  provide  interoperable 
business-quality  electronic  mail  throughout  all  Federal  government 
agencies. 

In  April,  1994,  the  EMTF  issued  its  final  report  which  defined 
business-quality  E-mail  as  "a  service  that  appears  to  the  user  to 
be  a single,  unified  electronic  postal  system  that  offers  robust 
arid  trustworthy  capabilities  with  legally-suff icient  controls  for 
moving  all  forms  of  electronic  information  among  employees  at  all 
levels  of  government,  and  with  the  public  we  serve?  and,  like  the 
nation's  telephone  network,  is  affordable,  ubiquitous,  efficient, 
accessible,  easy-to-use,  reliable,  cost-effective  and  supported  by 
an  effective  directory  service."  The  recommendations  of  the  EMTF 
included  the  following;  (1)  require  Government-wide  E-mail 
connectivity,  (2)  establish  a Government -wide  E-mail  Directory,  (3) 
establish  an  E-mail  Program  Office. 

The  EMTF  report  recommended  that  the  DOD  Defense  Messaging  System 
(DMS)  operational  characteristics  specifications  be  an  important 
source  of  information  to  be  used  when  defining  the  operational 
characteristics  of  business-quality  Government-wide  E-mail.  The 
Defense  Message  System  is  an  X.400-based  system  that  includes 
service  elements  added  to  the  commercial  Interpersonal  Messaging 
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User  Agent  (IPM-UA)  to  meet  the  Department  of  Defense  (DOD's) 
business-class  messaging  requirements.  The  contract  award  to 
implement  the  system  was  made  in  the  spring  of  1995. 

Security  services,  including  authentication,  integrity,  and 
confidentiality,  are  provided  by  algorithms  and  keys  that  are 
stored  on  a FORTEZZA  card  which  is  input  to  a Personal  Computer 
Memory  Card  Interface  Adapter  (PCMCIA) . The  FORTEZZA  PCMCIA  card 
interacts  with  an  Application  Programming  Interface  (API) , which 
expects  as  input  the  requested  security  services  and  the  algorithms 
and  keys  to  be  used  to  provide  those  services. 

DMS  Directory  Services  will  use  Directory  Service  Agents  and 
Directory  User  Agents  that  conform  to  the  ITU-T  X.500  Series  of 
Recommendations . 

In  . March  1995  DOD  issued  electronic  messaging  policy  and 
implementation  guidance  that  stated  that  the  DMS  will  meet  all  DOD 
messaging  requirements  and  will  be  used  to  provide  a single, 
seamless,  end-to-end  global  electronic  mail  service  within  DOD. 
The  policy  statement  further  directed  that  DOD  should  migrate  to 
DMS-compliant  messaging  as  rapidly  as  possible  and  imposed  a 
moratorium  on  the  acquisition  of  non-compliant  electronic  mail 
systems  unless  a transition  path  to  full  compliance  could  be 
documented . 

The  EMTF  recognized  however  that  Federal  agencies  outside  of  DOD 
may  have  different  requirements  for  business-class  messaging  than 
the  Department  of  Defense.  The  EMTF  recommended  that  an  Electronic 
Mail  Program  Management  Office  (PMO)  be  established  to  coordinate, 
shape  and  implement  policies  that  would  provide  electronic 
interoperability  among  Federal  agencies  and  between  each  Federal 
agency  and  the  outside  community  that  it  serves.  The  Office  of 
Management  and  Budget  (0MB)  chartered  and  funded  a group  within  the 
General  Services  Administration  (GSA)  to  perform  this  task. 

Business  quality  messaging,  as  currently  envisioned  by  the  GSA  E- 
mail  PMO,  includes  the  ability  to  send  and  receive  messages 
containing  both  text  and  binary  data  using  either  the  non- 
proprietary X.400  or  Simple  Mail  Transfer  Protocol  (SMTP) 
applications.  SMTP  must  include  MIME  functionality  in  order  to 
process  binary  data.  Directory  services  will  be  provided  by 
implementations  based  on  the  ITU-T  X.500  Series  of  Recommendations. 
Application  layer  gateways  will  be  needed  if  there  is  a requirement 
to  interconnect  X.400  and  SMTP  mail  systems. 

The  GSA  E-mail  PMO  has  developed  a two-year  plan  to  provide 
business  quality  messaging  to  Federal  agencies  by  1997. 
Government -wide  business  quality  messaging  however  will  not  happen 
without  the  active  participation  of  experts  from  all  Federal 
agencies.  The  GSA  E-mail  PMO  will  act  as  a coordinator  and 
catalyst  to  bring  Federal  agency  experts  together  to  develop  the 
detailed  functional  documents  that  specify  Federal  agency 
electronic  mail  and  directory  service  requirements  and  the  strategy 
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required  to  implement  those  requirements.  The  GSA  E-mail  PMO  will 
also  be  responsible  for  removing  all  barriers  that  would  inhibit 
the  implementation  of  that  strategy. 

Given  the  aforementioned  Federal  government  activity,  it  is 
recommended  that  each  Federal  agency  take  the  following  steps: 

(1)  Define  what  business  quality  messaging  means  for  your. agency 
Some  of  the  questions  that  need  to  be  answered  include:  What 
services  are  essential?  What  services,  although  not  essential, 
are  desirable?  Are  the  same  services  required  for  all  intra- 
agency and  inter-agency  communication  or  do  different  intra- 
agency groups  have  differing  requirements?  To  what  extent  are 
the  requirements  of  the  agency  affected  by  the  decisions  made 
by  users  outside  the  agency  - decisions  over  which  the  agency 
may  not  have  full  control?  What  are  the  agency's  security  and 
performance  requirements?  What  compromises  will  have  to  be 
made  because  procurement  funds  are  limited? 

(2)  Work  with  other  Federal  agencies  to  develop  a comaon 
specification  for  business  quality  messaging 

It  is  in  the  interest  of  each  Federal  agency  to  align  their 
requirements  for  business  quality  messaging  with  those  of  other 
agencies.  The  E-mail  PMO  has  established  the  means  by  which 
the  necessary  inter-agency  interaction  can  occur.  The  E-mail 
PMO  has  set  up  two  on-line  forums  to  facilitate  communication 
among  Federal  agencies  for  the  purpose  of  achieving  a consensus 
on  required  E-mail  services.  Federal  agency  personnel  can 
subscribe  to  one  or  both  on-line  forums  by  sending  an  e-mail 
message  to  listprocietc.fed.gov  with 

SUBSCRIBE  email -1  NAME  OF  SUBSCRIBER 
and/or 

SUBSCRIBE  X. 500-1  NAME  OF  SUBSCRIBER 
in  the  body  of  the  message.  To  get  a list  of  additional  on- 
line groups  that  deal  with  related  issues,  put  LIST  in  the  body 
of  the  message.  In  addition,  a volunteer  working  group  called 
the  Electronic  Messaging  and  Directory  Working  Group  (EMADWG) 
has  been  formed  to  address  a large  range  of  messaging  issues  at 
the  working  level.  For  further  information  about  E-mail  PMO 
sponsored  activities,  contact  Jack  Finley  at 
Jack. Finley §gsa . gov . 

(3)  Work  with  other  Federal  agencies  to  develop  a directory  service 
schema  to  support  business  quality  messaging 

The  E-mail  PMO  is  working  with  independent  contractors  to 
develop  a directory  services  schema  that  can  be  used  by  all 
Federal  agencies.  A directory  schema  consists  of  rules  which 
define  the  naming  of  entries,  the  content  of  entries  and 
attributes,  the  structure  of  the  directory  as  a whole  and  the 
hierarchical  relationships  between  entries.  An  entry  is  the 
universal  unit  of  information  storage  in  the  directory.  An 
entry  consists  of  one  or  more  attributes  which  can  be  mandatory 
or  optional  for  that  entry.  Each  entry  belongs  to  an  object 
class  which  governs  the  attributes  that  the  entry  must  or  may 
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contain  and  position  that  the  entry  may  take  in  the  Directory 
Information  Base  (DIB)  . The  DIB  is  organized  in  a tree-shaped 
hierarchy  known  as  the  Directory  Information  Tree  (DIT)  in 
which  each  entry  has  exactly  one  superior  entry  but  may  have 
many  subordinate  entries.  The  Directory  Service  Schema  will 
specify  a set  of  structure  rules  which  define  the  hierarchical 
relationships  that  will  exist  between  entries  of  different 
object  classes. 

The  Directory  Services  schema  that  is  being  developed  by  the 
E-mail  PMO  will  be  available  in  draft  form  for  comment  and 
approval  by  Federal  agencies.  Federal  agencies  should  ensure 
that  all  requirements  that  they  have  in  common  with  other 
agencies  are  incorporated  into  the  final  version.  The 
previously  mentioned  X.500  on-line  forum  and  the  EMADWG  will 
play  an  important  role  in  the  review  of  the  draft  document. 
Agencies  should  understand  that  the  schema  that  is  being 
produced  will  allow  them  to  add  object  classes  and  attributes 
of  particular  interest  to  their  agency. 

(4)  Determine  how  the  directory  service  will  be  administered  within 
your  agency 

The  DIT  can  be  broken  up  into  subtrees.  The  E-mail  PMO  will 
administer  the  portion  of  the  DIT  dealing  with  the  U.S. 
Government.  The  X.500  Directory  is  modeled  as  a distributed 
service;  it  can  consist  of  a number  of  Directory  System  Agents 
(DSAs) , each  of  which  holds  a portion  of  the  overall  Directory 
Information  Base.  The  E-mail  PMO,  under  its  authority  to 
administer  the  portion  of  the  DIT  under  Country=US, 
Organization=U.S.  Government,  will  assign  Organizational  Unit 
names  to  requesting  government  organizations  and  implement  a 
knowledge  reference  DSA  which  will  contain  the  address  of  all 
DSAs  that  implement  the  Directory  Service  at  the  Organizational 
Unit  level  of  the  DIT. 

Each  organization  that  requests  an  organizational  unit  name 
from  the  E-mail  PMO  must  decide  how  to  structure  and  administer 
the  subtree  in  the  DIT  that  contains  the  assigned 
Organizational  Unit  as  its  root  entry.  The  requesting 
organization  must  know  the  extent  of  its  administration 
authority.  For  example,  does  the  Department  of  Treasury  have 
the  authority  to  administer  the  name  space  for  the  Internal 
Revenue  Service?  If  so,  then  the  Internal  Revenue  Service 
becomes  a subordinate  Organizational  Unit  under  the  Department 
of  Treasury.  Does  the  Internal  Revenue  Service  have  the 
authority  to  request  and  administer  its  own  Organizational  Unit 
subtree?  There  is  no  correct  answer  but  policy  must  be 
determined  before  a request  for  the  assignment  of  an 
Organizational  Unit  name  is  made. 

Once  the  extent  of  the  administration  authority  of  an 
organization  is  determined,  the  next  issue  to  be  determined 
is  how  the  administrative  authority  is  to  be  partitioned  within 
the  organization.  Each  agency  must  determine  how  many  DSAs 
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will  provide  users  with  transparent  access  to  the  data  stored 
in  their  portion  of  the  DIT  and  what  part  of  the  DIT,  or  what 
naming  context,  is  the  responsibility  of  each  DSA. 

In  summary.  Federal  agencies  should  collaborate  to  develop  a common 
specification  for  business  quality  messaging.  The  E-mail  PMO  has 
set  up  mechanisms  to  facilitate  collaboration.  Although  the  EMTF 
has  stated  that  the  DMS  operational  characteristics  should  be  an 
important  input  to  this  process,  agencies  are  not  precluded  fi:om 
determining  that  the  SMTP  application  meets  the  business  needs  of 
their  agency  and  implementing  an  SMTP-X.400  gateway  to  reach  X.400 
users;  users  of  X.400  systems  will  also  require  a similar  gateway 
to  reach  SMTP  users.  The  X.500  Directory  Services  application, 
however,  appears  to  be  the  only  viable  means  of  providing 
government -wide  directory  services.  Users  should  understand  that 
use  of  X.500  Directory  Services  does  not  preclude  running  this 
application  over  the  TCP/IP  transport  and  network  protocols  (in 
fact,  this  is  the  most  likely  scenario)  . In  addition,  implementing 
the  X.500  Directory  Service  does  not  imply  use  of  the  X.400  mail 
service.  The  X.500  Directory  allows  an  attribute  type  hierarchy  to 
be  set  up  that  allows  X.400  addresses,  SMTP  addresses,  and  mail 
addresses  used  by  proprietary  systems  to  be  stored  and  accessed. 

The  OSI  (X.500)  Directory  Service  has  a good  chance  of  gaining 
marketplace  acceptance,  because  it  offers  more  functionality  than 
its  IPS  counterparts,  and  because  users  seem  to  want  and  require 
that  additional  functionality.  There  are  no  current  ISO/IEC  or 
ITU-T  standardization  activities  relating  to  major  functional 
extensions  for  OSI  Directory  Services. 

3.6  Electronic  Data  Interchange 

• 

Electronic  Data  Interchange  (EDI)  is  the  computer-to-computer 
transfer  of  structured  business  data,  including  Request  for 
Quotations  (RFQs) , purchase  orders  and  insurance  claim  forms. 

Early  electronic  data  interchange?  were  based  on  proprietary 
formats  agreed  between  two  trading  partners.  In  the  late  1970 's, 
the  American  National  Standards  Institute  (ANSI)  chartered  the 
Accredited  Standards  Committee  (ASC)  X12  to  create  a set  of 
standard  data  formats  to  facilitate  the  electronic  exchange  of 
business  information.  Each  year,  the  ASC  X12  Secretariat  publishes 
the  entire  set  of  the  latest  X12  standards  and  the  new  draft 
standards. 

Independently,  the  United  Nations  Economic  Commission  for  Europe 
created  another  family  of  standards  known  as  Electronic  Data 
Interchange  for  Administration,  Commerce  and  Transport  (EDIFACT) . 
Although  X12  is  more  mature  and  provides  functions  not  currently 
present  in  EDIFACT,  many  of  these  functions  are  currently  under 
development  in  the  EDIFACT  standards  community.  The  differences  in 
the  X12  and  EDIFACT  syntaxes;  however,  make  interoperation 
impractical.  Although  the  ASC  X12  committee  has  agreed  to  develop 
standards  based  both  on  the  X12  and  EDIFACT  syntaxes,  many  X12 
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users  view  switching  standards  as  a cost  with  little  financial 
return  and  have  resisted  a move  to  the  EDIFACT  standards. 

Thus,  development  of  X12  standards  will  continue  and  a vote  to 
reexamine  this  decision  will  be  taken  every  three  years  - the  next 
vote  will  occur  in  1998.  The  delay  in  sole  support  of  the  EDIFACT 
syntax  increases  the  likelihood  that  a decision  to  support  only  the 
EDIFACT  standards  will  never  occur.  As  more  and  more  X12 
transaction  sets  are  standardized,  users  will  have  a greater 
dependence  on  the  X12  standards  and  a transition  to  the  EDIFACT 
formats- will  become  even  more  difficult  than  it  is  now.  Thus, 
although  the  EDIFACT  standards  may  be  used  by  organizations  with 
international  electronic  data  interchange  requirements,  inertial 
forces  are  likely  to  lead  to  continued  use  of  the  X12  standards  for 
national  electronic  data  interchange  in  the  foreseeable  future. 

The  software  component  that  governs  the  conversion  of  application 
data  to  and  from  EDI  interchanges  is  called  an  EDI  translator.  For 
outbound  transactions,  an  application  writes  the  transaction  data 
to  a file.  The  translator  formats  the  data  according  to  the 
appropriate  EDI  syntax  rules  and  produces  an  EDI  file  that  is  ready 
to  be  communicated  to  the  trading  partner.  The  process  occurs  in 
reverse  for  inbound  transactions. 

The  communication  service  is  not  part  of  the  translation  process. 
The  EDI  standards  do  not  specify  how  EDI  documents  are  to  be 
transmitted  to  a trading  partner.  Most  EDI  trading  partners 
currently  use  the  services  of  a third  party  Value  Added  Network 
(VAN).  EDI  VANs  provide  a communications  network  to  connect 
trading  partners,  regardless  of  individual  hardware  platforms  or 
communications  protocols.  Each  partner  connects  to  the  VAN  and  the 
VAN  manages  the  connections  to  all  of  the  trading  partners.  VANs 
also  serve  as  a document  clearinghouse,  providing  a mailbox  service 
to  store  received  interchanges  until  a user  is  ready  to  download 
them.  VANs  may  provide  other  services  such  as  security,  directory, 
or  translation. 

In  order  to  provide  an  additional  method  for  transmitting  an  EDI 
document,  the  ITU-T  (then  the  CCITT)  issued  Recommendations  F.435 
[REF  16]  and  X.435  [REF  3]  to  specify  the  services  and  protocol  for 
an  EDI  User  Agent  (EDI-UA)  which  will  use  the  services  of  the 
Message  Transfer  Agent  [REF  2],  specified  in  the  1988  Series  of 
Recommendations  for  Message  Handling  Systems  to  transfer  an  EDI 
document  that  is  output  from  an  EDI  translator  as  a body  part  in 
the  content  of  an  X.400  message.  The  EDI  document  can  be  an  X12 
transaction  set,  an  EDIFACT  message  or  even  a privately  defined 
format.  Although  the  format  differs,  an  X12  transaction  set  and  an 
EDIFACT  message  are  functionally  similar,  i.e.,  both  can  be  used  to 
represent  a single  Request  for  Quotation  (RFQ)  or  a single  purchase 
order.  The  vendors  that  market  X.400  compliant  mail  systems 
generally  do  not  market  EDI  translators;  the  EDI  translator  has  to 
be  procured  separately.  Users  will  have  to  know  which  EDI 
translators  have  a compatible  interface  with  the  X.435  EDI  User 
Agent  that  they  are  procuring. 
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Each  organization  will  have  to  make  a decision  about  the 
communications  service  that  it  will  use  to  transfer  EDI  data. 
There  are  strong  obstacles  that  have  to  be  overcome  in  order  for 
X.435  to  become  the  preferred  means  of  transferring  EDI  documents. 
Organizations  are  not  likely  to  purchase  X.400  systems  primarily 
for  use  in  EDI;  a full-scale  commitment  to  use  X.400  services  will 
probably  be  needed  in  order  to  justify  the  procurement  costs.  Even 
in  those  organizations  that  choose  to  procure  X.400  systems,  there 
may  be  strong  resistance  to  changing  the  current  modus  operandi  if 
it  appears  to  be  working.  For  this  reason,  organizations  should 
not  procure  X.435  User  Agents  until  a comprehensive  EDI  policy  is 
agreed  both  by  the  organization  and  its  suppliers.  For  guidelines 
for  the  evaluation  of  EDI  products,  consult  [REF  17]. 

3.7  Message  Attachments 

A variety  of  word  processing  applications  are  in  widespread  use. 
Frequently,  there  is  a requirement  to  send  the  output  of  one  of 
these  applications  as  an  attachment  to  an  electronic  mail  message. 
Some  word  processing  applications,  including  WordPerfect  and 
Microsoft  Word,  output  files  in  binary  format,  other  formats  such 
as  LATEX  and  Rich  Text  Format  are  in  ASCII.  If  an  attachment  is  in 
binary  format  and  all  mail  systems  through  which  the  message  passes 
cannot  process  binary  data,  then  the  attachment  has  to  be  converted 
to  seven  bit  ASCII  before  transmission  and  converted  back  to  binary 
format  upon  receipt  before  further  processing  can  be  performed  on 
the  message.  In  UNIX  systems,  the  programs  UUENCODE  and  UUDECODE 
are  commonly  used  to  perform  the  required  encoding  and  decoding 
functions.  In  addition,  if  a large  amount  of  data  is  being  sent, 
it  may  be  desirable  to  compress  the  data  before  transmission.  If 
a binary  to  ASCII  conversion  is  necessary,  the  compression  will 
occur  before  the  conversion  to  ASCII  and  the  decompression  will 
occur  following  the  ASCII  to  binary  conversion  upon  receipt.  The 
compression/decompression  and  format  conversion  operations  are  not 
performed  by  the  mail  system;  they  have  to  be  performed  by  the 
originator  prior  to  transmission  and  by  the  recipient  after 
reception.  The  family  of  programs  that  perform  the  compression  and 
decompression,  as  well  as  the  encoding  and  decoding  programs,  have 
to  be  compatible. 

If. the  recipient's  electronic  mail  end  system  does  not  contain  a 
word  processing  application  that  is  capable  of  processing  the 
attachment,  then  the  message  has  to  be  downloaded  to  a system 
containing  such  an  application  (using;  for  example,  the  File 
Transfer  Protocol  (FTP) ) . Any  required  decoding  or  decompression 
in  order  to  create  a file  that  can  be  input  to  the  word  processing 
application  can  be  done  either  by  the  electronic  mail  end  system  or 
by  the  system  containing  the  word  processing  application  after  the 
file  is  transferred. 

New  versions  of  some  word  processing  applications  will  recognize 
and  convert  formats  other  than  their  own.  For  example.  Word 
Perfect  6.0  will  recognize  a file  in  Microsoft  Word  format  and 
convert  it  to  Word  Perfect  6.0  format.  It  can  then  be  read  or 
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printed  in  the  same  manner  as  any  other  Word  Perfect  6.0  file. 

Another  complicating  factor  in  the  forwarding  of  attachments  can 
occur  when  the  message  is  processed  by  a gateway  that  performs  the 
conversions  required  to  permit  two  different  mail  system  to 
interoperate.  The  gateway  must  be  able  to  determine  if  the 
attachment  is  in  ASCII  -or  binary  format  and,  if  the  attachment  is 
in  binary  format,  further  determine  that  the  mail  system  to  which 
the  message  is  being  forwarded  can  process  binary  data.  If  that 
mail  system  cannot  process  binary  data,  the  gateway  must  either 
call  a program  such  as  UUENCODE  to  convert  the  attachment  to  ASCII 
text  or  refuse  to  forward  the  message.  Recent  versions  of  the 
X.400  application  recognize  and  process  binary  data;  SMTP  must 
include  MIME  functionality  in  order  to  process  binary  data.  The 
bottom  line  is  that  as  long  as  heterogeneous  document  types  exist, 
users  that  mail  documents  as  attachments  to  electronic  mail 
messages  must  be  knowledgeable  about  the  ability  of  the 
interconnected  mail  systems  to  handle  binary  data  and  also  be 
knowledgeable  about  the  document  processing  applications  that  are 
available  to  all  recipients. 

3.8  File  Access 

FTAM  products  are  not  expected  to  be  plentiful,  because  of  their 
expense  and  the  existence  of  readily  available  alternatives,  such 
as  the  File  Transfer  Protocol  (FTP) . Only  a small  fraction  of  the 
functionality  specified  in  the  FTAM  standard  has  been  implemented 
in  FTAM  products.  Thus,  in  terms  of  functionality  available  in 
products.  Ftp  has  equivalent  functionality  in  terms  of  file 
transfer,  and  in  addition  has  file  directory  access  and 
manipulation  functionality  that  FTAM  products  do  not  possess. 

3.9  Information  Retrieval  (IR) 

IR  products  are  expected  to  become  numerous  in  the  next  few  years, 
in  part  because  of  the  growing  popularity  of  free  text  search  and 
retrieval  techniques.  Existing  products  contain  many  options 
relating  to  retrieval  efficiencies  and  particular  algorithms  to  be 
used.  Agencies  need  to  weigh  carefully  the  various  options  and 
features  of  the  available  product  offerings,  in  order  to  make  an 
informed  selection.  It  should  be  noted  that  in  many  cases, 
software  may  need  to  be  added  to  existing  IR  capability  to  provide 
a particular  optimization  or  a customized  user  interface. 

3.10  Remote  Datad^ase  Access  (RDA) 

The  RDA  protocol  establishes  a remote  connection  between  a database 
client  and  a database  server  and  allows  the  client  to  access  remote 
distributed  databases.  RDA  allows  access  to  the  database  systems 
built  by  different  vendors  using  the  SQL  database  access  language. 
RDA  does  not  preclude  the  use  of  other  database  access  languages; 
however,  only  the  SQL  specialization  has  been  standardized  and 
implemented. 
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Distributed  Query  Processors  (DQP)  can  easily  be  built  which  parse 
the  query  submitted  by  a client  and  use  RDA  to  access  the 
appropriate  database (s)  using  a directory  stored  in  the  DQP.  If 
the  query  requires  that  more  than  one  remote  database  system  be 
accessed,  the  returned  data  can  be  stored  in  the  DQP  until  all  data 
is  received,  then  the  data  can  be  merged  and  sent  to  the  client. 

RDA  eliminates  the  dependency  of  users  on  a single  database  system. 
For  that  reason,  even  though  RDA  products  are  beginning  to  appear 
in  the  market,  some  of  the  large  database  systems  vendors  are  not 
marketing  RDA  technology  and  probably  will  not  unless  there  is  user 
demand.  There  are  some  overhead  and  service  limitations  associated 
with  the  use  of  the  RDA  protocol.  Single-vendor  database  systems 
are  generally  more  efficient,  but,  for  many  users,  this  fact  is 
offset  by  the  ability  to  access  heterogeneous  database  systems. 

In  summary,  products  exist  but  may  not  be  aggressively  marketed  by 
vendors,  who  would  prefer  to  sell  their  proprietary  systems.  Until 
RDA  vendors  can  fully  establish  themselves  in  the  marketplace, 
users  will  have  to  determine  if  the  services  RDA  provides  are  worth 
minor  service  and  performance  degradations. 

3.11  Treuisaction  Processing 

On-line  Transaction  Processing  (OLTP) , developed  by  X/Open,  will  be 
popular  for  transaction  processing  applications.  It  has  many  of 
the  features  of  full  OSI  TP,  and  may  be  considered  a "subset"  of 
OSI  TP.  Products  are  available,  supported  by  many  vendors.  There 
are  few  full  OSI  TP  products  available,  and  few  are  anticipated. 
Users  should  consider  available  offerings  (such  as  OLTP)  for  their 
transaction  processing  functionality,  and  weigh  the  benefits  and 
features  of  any  options  or  enhancements  provided  by  vendors.  No 
further  extensions  are  planned  to  the  TP  standard.  There  is  no 
application  corresponding  to  OSI  TP  in  the  IPS. 

3.12  Network  Infrastructure 

Some  network  technologies  available  to  users  are  Asynchronous 
Transfer  Mode  (ATM) , frame  relay.  Switched  Multimegabit  Data 
Service  (SMDS) , narrowband  and  broadband  Integrated  Services 
Digital  Network  (ISDN) , Distributed  Queue  Dual  Bus  (DQDB) , Fiber 
Distributed  Data  Interface  (FDDI) , high-speed  Ethernet,  switched 
Ethernet,  and  wireless  LANs.  Many  of  these  technologies  are 
available  in  products  today,  and  many  more  products  will  be 
available  in  the  next  few  years.  Thus  there  is  a large  array  of 
choices  available  to  the  user.  It  is  likely  that  there  will  be  a 
multiplicity  of  network  technologies  into  the  foreseeable  future. 
In  addition,  more  and  more  agencies  are  replacing  traditional  media 
with  high-speed  fiber. 

It  should  be  noted  that  applications  described  in  this  paper  can 
employ  any  of  these  network  technologies  (since  the  transport 
functionality  "shields"  the  user  from  changes  in  underlying 
technology)  . These  network  technologies  can  be  used  in  combination 
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for  maximum  effectiveness.  For  example,  an  approach  gaining  in 
popularity  is  to  use  switched  Ethernet  over  an  ATM  backbone.  For 
more  information  on  ATM,  consult  [REF  18].  The  use  of  high-speed 
fiber  in  place  of  traditional  media  may  cause  changes  in  existing 
Transport  and  Network  layer  specifications,  including  IPng. 

3.13  APIs 

3.13.1  Electronic  Mail  API 

There  are  several  different  types  of  electronic  mail  application 
program  interfaces  (APIs) . Each  type  will  be  described  listing  the 
advantages  and  disadvantages  and  example  implementations. 

3.13.1.1  Client  APIs 

The  client  service  calls  in  this  type  of  API  are  not  tied  to  a 
particular  electronic  mail  implementation.  They  are  generic  (i.e.. , 
in  the  form  ReadMail  or  SendMail) . The  client  service  calls  are 
mapped  into  service  calls  to  another  client  API  for  a specific 
electronic  mail  implementation.  The  mapping  will  vary  with  each 
new  implementation.  Because  the  service  calls  are  generic,  the 
application  cannot  make  full  use  of  the  services  provided  by  the 
underlying  implementation.  The  Common  Mail  Call  (CMC)  API 
developed  by  the  X.400  API  association  is  an  example  of  this  type 
of  API. 


3.13.1.2  Server  Provider  Interface 

This  type  of  API  specifies  a server  provider  interface  which 
facilitates  the  mapping  of  the  generic  service  calls  into  the 
services  provided  by  different  electronic  mail  implementations. 
The  API  can  be  architected  so  that  both  client  and  server  make 
service  calls  to  an  operating  system.  The  Microsoft  Application 
Programming  Interface  (MAPI) , for  example,  provides  an  interface 
between  the  Common  Mail  Call  API  and  different  electronic  mail 
implementations  through  service  calls  to  the  Microsoft  operating 
system.  Alternatively,  the  API  can  be  implemented  outside  of  the 
operating  system  with  a plug-interface  specified  for  both  client 
and  server.  This  type  of  API  minimizes  the  software  that  has  to  be 
written  by  both  client  and  server. 

3.13.1.3  Specific  Implementation 

This  type  of  API  allows  the  client  to  make  maximum  usage  of  the 
services  provided  by  the  underlying  messaging  system.  The  service 
calls  are  not  generic  but  are  tailored  to  the  services  of  the  mail 
system.  The  disadvantage  of  this  type  of  API  is  that  it  binds  the 
client  to  the  services  of  one  mail  system;  changing  the  mail  system 
may  require  significant  modifications  to  the  client  application. 
X/Open,  the  X.400  API  Association  and  the  IEEE  developed  an  API 
which  is  linked  to  the  services  provided  by  the  X.400  Message 
Transfer  System  (MTS) . This  API  makes  X.400  MTS  services  available 
to  portable  user  agents  and  to  other  mail  systems  that  wish  to  use 
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X.400  as  a gateway. 

3.13.1.4  Mail  API  Sxunmary 

In  choosing  an  electronic  mail  API,  an  organization  must  consider 
whether  there  is  a strong  commitment  to  one  electronic  mail  system 
by  that  organization  or  whether  a more  flexible  solution  is 
required.  Other  factors  to  be  considered  include  availability  and 
cost.  Currently,  the  Microsoft  Application  Programming  Interface 
is  the  most  widely  implemented  electronic  mail  API. 

3.13.2  Transport  API 

RFC1006  allows  OSI  application  protocols  to  be  operated  over  an  IP 
network,  by  providing  the  OSI  Transport  Class  0 Service  over  the 
Internet  TCP.  RFC1006  products  are  growing  in  number. 

XTI  (X/Open  Transport  Interface)  provides  independence  from  any 
particular  transport  provider.  A truly  transport- independent 
application  can  be  written  using  XTI  if  no  assumptions  are  being 
made  by  the  application  about  the  nature  of  the  underlying 
transport  service.  XTI  functionality,  along  with  Sockets 
functionality,  is  included  in  an  IEEE-published  Protocol 
Independent  Interface  (PII)  specification. 

3.13.3  Other  APIs 

Several  APIs  have  been  developed  by  the  IEEE,  including;  (1) 
Association  Control  Service  Element  (ACSE) /Presentation  Layer  API, 
(2)  FTAM  API,  and  (3)  Directory  Services  API.  None  of  these  is 
likely  to  gain  wide  acceptance  in  products  over  the  next  several 
years,  for  several  reasons,  including  the  close  connections  with 
the  actual  protocols  with  which  they  interface.  APIs  which  provide 
a higher  degree  of  independence  are  likely  to  gain  more  acceptance 
by  the  user  community. 

3.14  Collaborative  Computing 

Collaborative  computing  may  be  defined  as  the  ability  of  two  or 
more  users  in  different  locations  to  interact  in  production  as 
though  they  were  in  the  same  room  (an  example  is 
videoconferencing) . Concurrent  engineering  refers  to  the 
development  of  the  distributed  infrastructure  necessary  for 
collaborative  computing  and  other  applications.  Groupware  may  be 
defined  as  the  software  ( or  middleware)  necessary  for  groups  to 
operate  effectively  in  a production-oriented  environment. 

Collaborative  computing  applications  may  use  the  protocols 
discussed  in  this  paper  to  provide  the  necessary  functionality  for 
productive  interaction,  or  these  applications  may  be  built  directly 
over  existing  infrastructures.  The  nature  of  the  existing 
infrastructure  may  determine  the  types  of  functionality  that  can  be 
supported  in  collaborative  computing  applications.  The  amount  and 
diversity  of  product  offerings  is  expected  to  expand  greatly  over 
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the  next  several  years,  with  the  tendency  towards  more 
sophisticated  products  and  functionality  (mirroring  the  development 
of  more  sophisticated  network  technologies) . 

Standards  bodies  (i.e.,  ITU-T  (formerly  CCITT) ) and  consortia 
(i.e.,  Object  Management  Group)  are  developing  collaborative 
computing  specifications.  In  addition,  vendors  are  developing 
their  own  approaches;  these  approaches  may  represent  "bundled" 
functionality,  or  stand-alone  functionality,  and  vendors  are  also 
joining  forces  to  combine  functionality  into  larger  packages.  NIST 
is  setting  up  a laboratory  to  demonstrate  and  test  collaborative 
computing  applications.  The  most  advanced  products  offer  a 
complete  set  of  tools  in  one  product.  Examples  of  such  tools 
include:  (1)  searching  on  electronic  mail,  (2)  maintaining  "chat" 
sessions,  (3)  searching,  managing  and  sharing  documents,  and  (4) 
sophisticated  communication  between  servers.  Growth  areas  include 
the  development  of  a multimedia  capability,  improved  security  and 
the  integration  of  existing  infrastructures.  The  separate 
development  of  WWW  servers  and  Internet  newsgroups  may  impact  the 
collaborative  computing  market  in  the  years  to  come. 

3.15  Gateways 

Gateways  for  applications  other  than  messaging  applications  are 
likely  to  be  unwieldy  and  cumbersome.  The  messaging  application  is 
most  adaptable  to  being  gatewayed  because  it,  alone,  of  all  the 
standardized  applications,  is  modeled  as  a store  and  forward 
application.  The  implementation  of  an  application  gateway  for 
other  applications  will  transform  those  applications  into  store  and 
forward  applications.  Since  they  were  not  so  designed,  the  end 
result  is  likely  to  be  a noticeable  performance  degradation. 

Mail  gateways  are  application  layer  gateways  that  can  vary  in 
design.  Mail  gateways  can  be  tailored  for  two  specific  mail 
applications.  This  maximizes  the  services  that  can  be  provided,  at 
the  expense  of  flexibility.  Another  solution  is  to  have  a common 
mail  gateway  to  serve  all  applications.  The  X.400  protocol  is  most 
suitable  for  this  purpose  because  it  provides  a superset  of  the 
services  of  most  mail  applications.  But  any  gateway  can  only 
provide  the  service  subset  that  the  two  gatewayed  mail  protocols 
and  the  gatewaying  protocol  have  in  common.  A user  served  by  mail 
application  A that  is  gatewayed  to  mail  applications  B,  C,  and  D 
will  most  likely  be  provided  with  services  that  will  differ 
depending  upon  the  application  that  generated  the  message.  This 
can  become  more  annoying  and  exasperating  to  users  as  more  and  more 
mail  applications  are  gatewayed  and  may  lead  to  decreased  usage  of 
electronic  mail  for  communication. 

The  bottom  line  is  that  mail  gateways  may  have  an  important  role  to 
play  in  a transition  to  a single  mail  system  or  in  allowing 
interoperability  with  a community  of  users  that  will  continue  to  be 
served  by  another  mail  application.  Users,  however,  should  not 
look  upon  them  as  an  interoperability  panacea.  They  have 
significant  drawbacks  that  should  be  understood  before  they  are 
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widely  implemented.  The  fewer  gateways  that  are  implemented,  the 
better. 

3.16  Consortia 

It  is  considered  that  some  consortia  have  formed  for  the  wrong 
reasons  (that  is,  they  are  reactive,  not  proactive) . In  addition, 
consortia  are  usually  closed,  so  there  has  long  been  a resistance 
to  adopting  their  standards  (possible  antitrust  concerns). 
However,  the  specifications  may  be  closely  tied  to  operational 
environments,  and  may  be  based  on  implemenation  experience.  So, 
for  these  reasons,  plus  the  fact  that  comprehensive  solutions  may 
be  included , there  is  strong  consideration  towards  adopting  these 
consortium-based  models  by  some  end  users. 

It  is  still  unclear  which  consortia-based  networking  products,  if 
any,  will  gain  widespread  acceptance.  Vendors  may  be  using 
consortia  to  promote  their  own  proprietary  solutions,  and  users  are 
likely  to  evaluate  implementations  based  on  consort ia-devel oped 
stnadards  on  a case-by-case  basis. 

As  an  example,  more  detail  needs  to  be  added,  and  more 
implementation  experience  gained,  before  CORBA  gains  widespread 
acceptance.  In  particular,  it  is  unclear  whether  CORBA  is  merely 
a linkage  connecting  proprietary  ORBs  or  is  truly  an  open  systems 
solution.  A viable  CORBA-to-DCE  link  should  greatly  enhance 
CORBA 's  acceptance.  The  CORBA  RPC  should  be  considered  as  an 
alternative  to  DCE  RPC  and  OSI  in  terms  of  establishing 
communications . 

DCE  products  haave  a presence  in  the  marketplace  currently,  but  the 
complexity  of  DCE  poses  concerns  for  future  growth.  Applications 
which  have  important  security  requirements  may  continue  to  take 
advantage  of  DCE  capability.  User  requirements  are  being  gathered 
for  the  next  generation  of  DCE  functionality,  called  "DCE  2000". 
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4.0  Summary 


The  absence  of  a single  solution  for  providing  worldwide  computer 
interoperability  places  more  responsibility  on  procurement 
authorities  to  make  the  right  choice.  In  order  to  make  intelligent 
procurement  decisions,  procurement  authorities  will  have  to  be 
informed,  both  about  the  technical  features  and  marketplace 
acceptance  of  these  products , to  a degree  that  was  not  previously 
anticipated.  This  Data  Communications  Strategy  document  provides 
procurement,  managerial  and  technical  personnel  with  some  of  the 
factors  that  need  to  be  considered  when  making  these  decisions. 


49 


APPENDIX  A.  Testing 

There  are  four  categories  of  testing  that  should  be  considered  when 
procuring  computer  networking  products:  conformance  testing, 
interoperability  testing,  performance  testing  and  functional 
testing.  Conformance  testing  verifies  that  an  implementation  acts 
in  accordance  with  a particular  specification.  Interoperability 
testing  duplicates  the  "real-life"  environment  in  which  an 
implementation  will  be  used.  Performance  testing  measures  whether 
an  implementation  satisfies  the  performance  criteria  of  the  user. 
Functional  testing  determines  the  extent  to  which  an  implementation 
meets  user  functional  requirements. 

If  appropriate,  users  may  require  vendors  to  demonstrate 
conformance  and  interoperability  by  consulting  NISTIR  4594,  "GOSIP 
Conformance  and  Interoperation  Testing  and  Registration"  [REF  19]. 
A register  of  OSI  products  is  maintained  for  the  convenience  of 
those  agencies  that  wish  to  acquire  products  based  on  OSI 
standards . 

The  Joint  Interoperability  Test  Center  (JITC)  at  Fort  Huachuca 
maintains  an  online  database  facility  that  provides  information  for 
the  following  list  of  registers;  (1)  OSI  Abstract  Test  Suite  (ATS) 
(a  test  suite  that  is  independent  of  any  specific  implementation) , 
(2)  Assessed  Means  of  Testing  (MOT)  (specific  implementation  of  one 
or  more  ATS) , (3)  National  Voluntary  Laboratory  Program  (NVLAP) 
Accredited  Test  Laboratories  (laboratories  found  competent  to 
perform  specified  testing  operations) , (4)  Conformance  Tested  OSI 
Products  (a  list  of  products  that  have  gone  through  the  Conformance 
Testing  process) , (5)  Interoperability  Test  Suites  (ITS)  for  OSI 
Products  (public  test  scripts  specified  in  terms  of  abstract 
services  requited  for  interoperability)  , (6)  Reference  Entities  for 
Means  of  Testing  Assessment (s)  (publicly  available  implementations 
that  can  be  used  as  a standard  in  evaluating  other  implementations 
or  test  systems)  , and  (7)  interoperability  Test  and  Registration 
Services  (organizations  which  provide  interoperability  test 
results) . These  files  are  available  for  downloading  and  may  be 
accessed  via  anonymous  ftp  over  the  Internet  from  IP  address  - 
138.27.7.2.  For  any  questions  or  comments  dealing  with  this 
database  please  contact:  Joint  Interoperability  Test  Center  - TCBB, 
Fort  Huachuca,  AZ  85613-7020,  or  email:  C3A-TCB§huachuca- 
EMH2.army.mil.  A Uniform  Resource  Locator  (URL)  is  available  as 
follows:  ftp://138 . 27 . 7 . 2/public/GOSIP.html . This  URL  contains 
information  on  the  above-mentioned  files,  plus  additional 
information  on  related  topics. 

Interoperability  test  results  have  been  available  from  OSINET  (a 
consortium  of  U.S.  vendors  and  users) , however,  OSINET  ceased  to 
exist  as  of  December  31,  1995,  and  functions  were  transferred  to 
OSIONE  (a  parent  organization  to  OSINET,  and  an  organization  with 
worldwide  membership) . The  secretariat  for  OSIONE  is  in  Brazil; 
for  more  information,  contact  toledo@brisa.org.br. 
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APPENDIX  B.  List  of  Acronyms 


ACSE 

ANSI 

API 

ARPA 

ASCII 

ATM 

CCITT 

Cl  DR 

CLI 

CLNP 

CMC 

CMIP 

CONS 

CORBA 

DARPA 

DCA 

DCE 

DIT 

DNS 

DOD 

DQDB 

DQP 

DUA 

DSA 

EBCDIC 

EDI 

EDI FACT 

EDI-UA 

EMTF 

FTAM 

FTP 

GOSIP 

GSA 

HTML 

HTTP 

lAB 

lACB 

lEC 

IEEE 

lESG 

IETF 

IIMC 

IP 

IPM-UA 

IPS 

IR 

IRTF 

ISDN 

ISOC 

ITS 


Association  Control  Service  Element 
American  National  Standards  Institute 
Application  Programming  Interface 
Advanced  Research  Projects  Agency 

American  Standard  Code  for  Information  Interchange 
Asynchronous  Transfer  Mode 

Consultative  Committee  for  International  Telegraphy  and 
Telephony 

Classless  Interdomain  Routing 
Call  Level  Interface 
Connectionless  Network  Protocol 
Common  Mail  Call 

Common  Management  Information  Protocol 
Connection-oriented  Network  Service 
Common  Object  Request  Broker  Architecture 
Defense  Advanced  Research  Projects  Agency 
Defense  Communications  Agency 
Distributed  Computing  Environment 
Directory  Information  Tree 
Domain  Name  Server 
Department  of  Defense 
Distributed  Queue  Dual  Bus 
Distributed  Query  Processors 
Directory  User  Agent 
Directory  System  Agent 

Extended  Binary  Coded  Decimal  Interchange  Code 
Electronic  Data  Interchange 

Electronic  Data  Interchange  for  Administration,  Commerce 
and  Transport 

Electronic  Data  Interchange-User  Agent 
Electronic  Mail  Task  Force 
File  Transfer,  Access  and  Management 
File  Transfer  Protocol 

Government  Open  Systems  Interconnection  Profile 

General  Services  Administration 

Hypertext  Markup  Language 

Hypertext  Transfer  Protocol 

Internet  Architecture  Board 

Internet  Advisory  Control  Board 

International  Electrotechnical  Commission 

Institute  of  Electrical  and  Electronics  Engineers 

Internet  Engineering  Steering  Group 

Internet  Engineering  Task  Force 

ISO  Internet  Management  Coexistence 

Internet  Protocol 

Interpersonal  Messaging  User  Agent 
Internet  Protocol  Suite 
Information  Retrieval 
Internet  Research  Task  Force 
Integrated  Services  Digital  Network 
Internet  Society 
Interoperability  Test  Suite 
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ITU-T 

JITC 

JTCl 

LAN 

LLC 

MAPI 

MIB 

MIME 

MIT 

MMS 

MOT 

MTA 

MTS 

NASA 

NIST 

NSF 

NSFNET 

OLTP 

0MB 

OMG 

ORB 

OS  I 

PCMCIA 

PEM 

PII 

PMO 

RDA 

RFC 

RFQ 

RPC 

SMI 

SMDS 

SNMP 

SMTP 

TCP 

TP 

UA 

UDP 

USENET 

VAN 

VT 

WAIS 

WWW 

XTI 


International  Telecommunications  Union-Telecommunications 
Joint  Interoperability  Test  Center 
Joint  Technical  Committee  1 
Local  Area  Network 
Logical  Link  Control 

Microsoft  Application  Programming  Interface 
Management  Information  Base 
Multi-media  Mail  Extensions 
Massachusetts  Institute  of  Technology 
Manufacturing  Messaging  Specification 
Means  of  Testing 
Message  Transfer  Agent 
Message  Transfer  System 

National  Aeronautics  and  Space  Administration 

National  Institute  of  Standards  and  Technology 

National  Science  Foundation 

National  Science  Foundation  Network 

On-line  Transaction  Processing 

Office  of  Management  and  Budget 

Object  Management  Group 

Object  Request  Broker 

Open  Systems  Interconnection 

Personal  Computer  Memory  Card  Interface  Adapter 

Privacy  Enhanced  Mail 

Protocol  Independent  Interface 

Project  Management  Office 

Remote  Database  Access 

Request  for  Comments 

Request  for  Quotations 

Remote  Procedure  Call 

Structure  of  Management  Information 

Switched  Multimegabit  Data  Service 

Simple  Network  Management  Protocol 

Simple  Mail  Transfer  Protocol 

Transmission  Control  Protocol 

Transaction  Processing 

User  Agent 

User  Datagram  Protocol 

User's  Network 

Value  Added  Network 

Virtual  Terminal 

Wide  Area  Information  Server 

World  Wide  Web 

X/Open  Transport  Interface 


52 


REFERENCES 


1.  CCITT  Recommendation  X.400  series  (Red  Book,  1984) , Message 
Handling  Systems 

2.  CCITT  Recommendation  X.400  series  (Blue  Book,  1988),  Message 
Handling  Systems 

3.  CCITT  Recommendation  X.435  - Message  Handling  Systems:  EDI 
Messaging  System  (1991) 

4 . Information  Processing  Systems  - Open  Systems  Interconnection  - 
File  Transfer  Access  and  Management  ISO  8571 

5.  Information  Processing  Systems  - Open  Systems  Interconnection  - 
Virtual  Terminal  Basic  Class  ISO  9041 

6.  Information  Processing  Systems  - Open  Systems  Interconnection  - 
Transaction  Processing  ISO  10026 

7.  Information  Processing  Systems  - Open  Systems  Interconnection  - 
Remote  Database  Access  ISO  9579 

8.  ISO/IEC  9075  - Database  Language  SQL 

9.  CCITT  Recommendation  X.500  series  The  Directory,  1992 

10.  Information  and  Docximentation-Search  and  Retrieve  Application 
Protocol  Specification  for  Open  Systems  Interconnection,  ISO 
10163 

11.  Industrial  Automation  Systems  - Manufacturing  Message 

Specification  ISO  9506 

12.  Information  Technology  - Open  Systems  Interconnection  - Systems 
Management  ISO  10164 

13.  RFC  1006,  1987.  Rose,  M.  "ISO  Transport  Services  on  Top  of  the 
TCP.”  Internet  Request  for  Comments  (May) 

14.  Federal  Information  Processing  Standard  186,  Digital  Signature 
Standard,  1994,  available  from  NTIS 

15.  Federal  Information  Processing  Standard  46-2,  Data  Encryption 
Standard  (DES) , 1993 

16.  CCITT  Recommendation  F.435  - Message  Handling  Systems:  EDI 
Messaging  Service  (1991) 

17.  Guidelines  for  the  Evaluation  of  Electronic  Data  Interchange 
Products,  NIST  CSL/NSA  Technical  Report,  August  1995 

18.  Asynchronous  Transfer  Mode  Procurement  and  Usage  Guide,  NISTIR 


53 


4435,  October  1994 

19.  GOSIP  Conformance  and  Interoperation  Testing  and  Registration, 
March  1991,  Version  1.0,  NISTIR  4594 


54 


i.  • • 


I 

- '1 


